Глагол REST для изменения состояния - можем ли мы договориться о POST?
Эталонной реализацией REST является World Wide Web, которая была катастрофически успешной, хотя HTML (доминирующий тип мультимедиа) указывал только поддержку GET и POST.
Использование POST для небезопасных операций - штраф .
Хотя start выглядит как глагол (нарушающий REST-практики)
Нет - REST не заботится о написании URI. Это часть вопроса: сервер может изменять URI в ссылках в любое время, когда ему нравится, потому что клиенты просто переходят по ссылкам.
Тем не менее, существует проблема с вашими предлагаемыми идентификаторами, которые вы, возможно, захотите рассмотреть
/coffeemachines/{id}
/coffeemachines/{id}/start
Что касается REST, то это разные ресурсы. Это означает, что ваша локально кэшированная копия /coffeemachines/{id} не является недействительной , когда вы POST запрашиваете /coffeemachines/{id}/start.
Если вы хотите воспользоваться преимуществами поддержки кэширования, которая уже встроена в доступные компоненты, независимые от домена, то вы хотите, чтобы цель POST соответствовала цели GET: /coffeemachines/{id}
/coffeemachines/{id}/start, в этом дизайне, не является целью POST, но вместо этого является идентификатором ресурса формы, который отправляет стартовые сообщения в /coffeemachines/{id}. Аналогично, /coffeemachines/{id}/stop идентифицирует ресурс формы, который отправляет сообщения остановки.
Представление кофемашины будет включать ссылки на эти формы, когда переходы разрешены; например, когда кофемашина выключена, тогда представление кофемашины, возвращаемое GET, будет включать ссылку на форму запуска, но не ссылку на форму остановки.
/coffeemachines/{id}/start и /coffeemachines/{id}/stop являются ресурсами, отличными от /coffeemachines/{id}, и поэтому могут иметь свои собственные политики кэширования.
Конечно, не требуется , чтобы формы были отдельными ресурсами - механизм также работал бы, если бы формы были частью представления самого ресурса /coffeemachines/{id}.
Могу ли я попросить вас рассказать о POST против PATCH
Я обнаружил, что это наблюдение Роя Филдинга помогло мне:
HTTP не пытается требовать, чтобы результаты GET были безопасными. Для этого требуется, чтобы семантика операции была безопасной, и, следовательно, это ошибка реализации, а не интерфейса или пользователя этого интерфейса, если в результате произойдет что-либо, что приведет к потере свойства
PATCH имеет более строгую семантику, чем POST ; это означает, что клиенты (и общие компоненты) могут сделать более сильные предположения о том, что происходит.
Итак, в следующих примерах:
PATCH /foo HTTP/1.1
Content-Type: application/json-patch+json
POST /foo HTTP/1.1
Content-Type: application/json-patch+json
Сервер может обрабатывать эти сообщения точно так же. Клиенты, которые распознают метод PATCH, распознают, что небезопасные изменения на сервере должны быть «все или ничего» («Сервер ДОЛЖЕН применять весь набор изменений атомарно ...») и могут использовать это по своему усмотрению, но с POST это дополнительное ограничение отсутствует и не может быть принято.
Примечания к спецификации PATCH:
Сравнение с POST еще сложнее, поскольку POST используется в самых разных целях и может охватывать операции, подобные PUT и PATCH, если сервер выберет. Если операция не изменяет ресурс, идентифицируемый Request-URI предсказуемым образом, следует рассмотреть POST вместо PATCH или PUT.