Использование команд LINK и UNLINK HTTP в REST API

в настоящее время я работаю над реализацией REST API. У меня есть модель ресурсов с большим количеством связей между отдельными ресурсами.

мой вопрос: как вы связываете два существующих ресурса друг с другом (устанавливая отношения) в спокойной манере?

одним из решений, с которым я столкнулся, было использование ссылки и UNLINK http-глаголов. Потребитель API сможет связать два ресурса, используя LINK и следующий URI: /ресурс1/:id1 в/resource2/:ID2, которое.

проблема с этим решением заключается в отсутствии поддержки глаголов LINK и UNLINK. Ни http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html или http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol упомяните глаголы, и они, кажется, в значительной степени "забыты". Однако в исходном RFC 2068 указано, что они существуют.

Мне очень нравится это решение. Однако, я боюсь, что многие API потребители / клиенты не смогут справиться с решением из-за отсутствия поддержки LINK/UNLINK. Является ли это приемлемым решением или есть какие-либо лучшие и/или более элегантные решения для связывания существующих ресурсов в RESTful API?

спасибо

21
api httpverbs rest

1 ответов

я использую LINK и UNLINK в моем (на заказ, компания-внутренний) веб-приложение. Я использую http://tools.ietf.org/html/draft-snell-link-method как мой эталонной реализации.

я нашел, что есть три типа клиентов:

  1. те, которые поддерживают только GET и POST, принимая их сигналы из HTML <form> элемент.
  2. те, которые поддерживают только GET, PUT, POST и DELETE. Они берут свои сигналы от CRUD и API типа RPC-pretending-to-be-REST.
  3. те, которые позволяют любой метод. Публикация PATCH как официальный RFC увеличил их количество, как и рост WebDAV, хотя иногда клиенты категории 2 поддерживают PATCH тоже.

поскольку мы в настоящее время разрабатываем наших клиентов в доме, у нас нет этой проблемы, но я изучил ее и рассмотрел плюсы и минусы, прежде чем определить мой API, в случае, если мы хотим разрешить сторонним клиентам. Мое решение (так как нам все равно нужно было поддерживать HTML-клиентов без Javascript) было разрешить POST чтобы переопределить метод, указав

24