Могу ли я использовать только глаголы POST и PATCH?
В большинстве случаев вы будете использовать POST.
PUT, а PATCH определены с удаленным созданием семантика - это методы, используемые для копирования новых представлений ресурса с клиента на сервер. Например, клиентское GET sa представление /project/12345, вносит локальные изменения, а затем использует PUT, чтобы запросить, чтобы сервер принял новое представление ресурса клиента как свое собственное.
PATCH, семантически это аналогичный обмен сообщениями с той разницей, что вместо отправки полного представления ресурса клиент возвращает «патч-документ», который сервер может применить к своей копии для внесения изменений.
Теперь технически документация PATCH накладывает какие-либо ограничения на то, что такое «патч-документ». Однако для того, чтобы PATCH был более полезным, чем POST, нам нужны форматы документов исправлений, которые являются универсальными и широко признанными (например, application/merge-patch+json или application/json-patch+json).
И это не совсем случай, который у вас есть здесь, где вы определяете командные сообщения, которые c относятся к вашему домену.
Более того, семантика удаленного создания не очень хорошо согласуется с «моделированием домена» (которое является частью наследия CQRS). Когда мы моделируем домен, мы обычно даем модели домена право решать, как интегрировать новую информацию с тем, что сервер уже знает. Семантика PUT и PATCH больше похожа на то, что вы использовали бы для записи информации в хранилище данных anemi c.
С другой стороны, можно использовать POST
POST служит многим полезным целям в HTTP, включая общую цель «это действие не стоит стандартизировать». - Fielding, 2009
Можно вспомнить, что REST - это архитектурный стиль всемирной паутины, и единственный небезопасный метод, поддерживаемый html, - это POST.
Поэтому замените команды PATCH на POST, и вы на правильном пути.
Fielding, 2008
Я также должен отметить, что приведенное выше не но полностью RESTful, по крайней мере, как я использую этот термин. Все, что я сделал, это описал сервисные интерфейсы, что не больше, чем у любого RP C. Чтобы сделать его RESTful, мне нужно было бы добавить гипертекст, чтобы представить и определить службу, описать, как выполнять сопоставление с использованием форм и / или шаблонов ссылок, и предоставить код для объединения визуализаций полезными способами. Я мог бы даже go дальше и определить эти отношения как стандартные, так же, как Atom стандартизировал нормальный набор HTTP-отношений с ожидаемой семантикой.
То же самое и здесь - мы еще не достигли " REST ", но мы улучшили ситуацию, выбрав стандартизированные методы, которые лучше соответствуют нашей предполагаемой семантике.
И последнее замечание - вам, вероятно, также следует заменить использование DELETE на POST. DELETE потенциально является проблемой по двум причинам: семантика не такая, как вы хотите, и стандартная полезная нагрузка удаления имеет не определена семантика
Выражается по-другому: DELETE из передача документов по сети домен, а не ваш домен. Следует понимать, что сообщение DELETE, отправленное вашим ресурсам, означает то же самое, что и сообщение DELETE, отправленное на любой другой ресурс. Это единое ограничение интерфейса в действии: мы все согласны с тем, что токены HTTP-методов означают одно и то же везде .
Относительно небольшое количество ресурсов позволяет использовать метод DELETE - его основное использование для сред удаленного авторинга, где у пользователя есть какое-то направление в отношении его воздействия - RF C 7231
Как и раньше: семантика удаленного авторинга явно не подходит для отправки сообщения модели предметной области.