Как правильно запросить REST API для GET & DELETE без ID ресурса?
С точки зрения REST этот вопрос не имеет большого смысла. Любая именованная информация может быть ресурсом , и мы используем идентификатор ресурса (он же URI), чтобы определить, о каком ресурсе мы говорим.
GET /api/users?active
В этом запросе /api/users?active - это идентификатор ресурса (то, что в RF C 7230 называется запрос-цель , выраженный в исходной форме).
Ваш ресурс, в данном случае это «все активные пользователи», или, точнее, «список всех активных пользователей»; представление этого списка со временем будет меняться в зависимости от того, какие пользователи в данный момент активны.
GET /api/users/active/messages
Та же идея, ресурс - это список сообщений.
Теперь обычно, когда мы пытаемся чтобы изменить ресурс, мы используем идентификатор ресурса в качестве target-uri для изменения. Таким образом, все изменения в списке сообщений будут иметь общий target-uri
POST /api/users/active/messages
PUT /api/users/active/messages
PATCH /api/users/active/messages
DELETE /api/users/active/messages
Это связано с тем, что URI служит в качестве ключа кэша, а компоненты общего назначения, знакомые с семантикой кэширования HTTP, будут знать делает недействительными любые ранее кэшированные представления ресурса.
В HTTP DELETE имеет точное значение semanti c, которое заключается в удалении ассоциации между идентификатором и его представления. Естественным следствием успешного удаления является то, что последующий запрос GET вернет 404 Not Found (что означает, что запрошенный target-uri не имеет текущего представления).
Если то, что вы намереваетесь для изменения представления, тогда POST / PUT / PATCH - более естественный выбор.
PUT /api/users/active/messages
Content-Type: application/json
[]
- это сообщение, которое означает «заменить текущее представление этим».
Замена одного Представление с другим довольно тривиально, когда ваша реализация является просто хранилищем документов - вы проверяете входящее представление, а затем перезаписываете старое представление новым. С динамически сгенерированными представлениями поддержка одной и той же семантики - намного больше работы.
Это может значительно облегчить вашу жизнь, чтобы POST запрос «удалить все сообщения» к ресурсу, а не пытаться PUT нового представления.