Использование LINK и UNLINK HTTP-глаголов в REST API

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

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

Одним из решений, с которым я столкнулся, было использование глаголов LINK и UNLINK HTTP. Пользователь API мог бы связать два ресурса с помощью LINK и следующего URI:/resource1/: 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. Является ли это приемлемым решением или есть лучшие и/или более элегантные решения для связывания существующих ресурсов в API RESTful?

Спасибо

Ответы

Ответ 1

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

Я обнаружил, что существует три типа клиентов:

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

Поскольку мы в настоящее время разрабатываем наших клиентов внутри компании, у нас нет этой проблемы, но я изучил ее и рассматривал плюсы и минусы до определения моего API, если мы действительно хотим разрешить сторонние клиенты. Мое решение (так как в любом случае нам нужно было поддерживать HTML-клиент без Javascript) было позволить POST переопределить метод, указав поле _METHOD (application/x-www-form-urlencoded), а затем на моей внутренней стороне > выкл к соответствующей функции для предполагаемого метода HTTP. Таким образом, любой клиент в будущем, который находится, скажем, в классе 2 выше, может использовать PUT и DELETE, но обернуть PATCH, LINK и UNLINK в запросе POST. Вы получаете лучшее из обоих миров: богатые методы от клиентов, которые его поддерживают, и все же поддерживают низкокачественные клиенты через POST-туннелирование.