Об этом много раз спрашивали на дискуссионных форумах HAL https://groups.google.com/forum/#!forum/hal-discuss
Тот факт, что глаголы не возвращаются, является решением используемого вами формата гипермедиа, который, как я предполагаю, является HAL (или, может быть, коллекция + json). Некоторые форматы ДЕЙСТВИТЕЛЬНО включают информацию о глаголах.
HAL на самом деле позволяет вам включать настраиваемые поля в ваши объекты ссылок, если вы хотите, но я бы не рекомендовал это, потому что любой стандартный клиент не будет знать, как это интерпретировать.
Но также я обнаружил, что глагол в конце концов бесполезен.
Прежде всего, в человеко-машине 2 пользователь будет читать документацию. HAL имеет разыменование всех своих ссылок (через CURIE, поскольку они в настоящее время называются naemd) на удобочитаемую документацию, которая должна описывать эффекты запроса этой ссылки с различными параметрами, глаголами, заголовками и т. д.
Далее, чтобы ваше приложение было действительно RESTful, вы должны реагировать на все глаголы... вы можете просто не отвечать, что глагол был в порядке. Для приложения на основе HTTP, возвращающего 405, ОЧЕНЬ подходит. Возврат 404 невозможен! 500 было бы хуже!. Ваш 405 должен включать, какие методы доступны для запрошенного ресурса.
Затем, в случае машины 2 (и немного h2m), ваше приложение при доступе через HTTP (я стараюсь избегать http в своих ответах, поскольку приложения RESTful не обязательно являются HTTP ... хотя я бы сказал, что 101% из них ) следует использовать метод OPTIONS (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) по URL-адресу ресурса, чтобы получить описание возможных вариантов.
Вот где я вижу, как многие люди сбиваются с толку, каким должен быть ответ OPTIONS? ну, что люди забывают, так это согласование типа контента! Заявитель должен указать, какой формат информации об опциях он ожидает. Примите: какой-то машинный язык/xml или приложение/язык+json. Некоторые RFC или стандарты определяют эти типы контента, и ваш API может определить, какие форматы он поддерживает. Я бы посоветовал вам включить поддержку text/html, чтобы вы также могли возвращать удобочитаемую документацию о том, какие глаголы поддерживаются. Это хорошо покрывает сценарий h2m.
Такое же согласование типа содержимого может быть полезно при возврате информации о неподдерживаемом методе. Сервер может отправить тип контента, понятный клиенту, который семантически описывает, какие методы разрешены.
Последнее, на что я хотел бы обратить внимание, это то, что методы подразумевают намерение клиента. я хочу ПОСТАВИТЬ этот ресурс или УДАЛИТЬ этот ресурс. Сервер должен принимать запросы и возвращать ответы, указывающие, какие переходы состояний произошли из-за этого запроса. Таким образом, немного глупо заставлять API определять возможные намерения клиента при каждом запросе. Клиент знает, что он хочет сделать, он должен попытаться, а если не сможет, то должен с этим справиться.
person
Chris DaMour
schedule
23.01.2015
