Дизайн API REST в отношении метода УДАЛЕНИЯ

Я создаю API REST. на самом деле я понимаю общее руководство и правило.

Но у меня проблема с методом УДАЛЕНИЯ, потому что мне нужно отправить данные по телу в запросе, который метод УДАЛЕНИЯ проигнорирует тело.

Если вы спрашиваете, какие данные заставляют меня отправлять их по телу в методе УДАЛЕНИЯ, это "URL" и какой-то другой параметр. Конечно, у "url" есть идентификатор в базе данных, поэтому я могу без проблем использовать DELETE, например DELETE https://api.example.com/content/url:url_id. Но вместо того, чтобы передать удостоверение личности, я выбрал чтобы передать URL-адрес самостоятельно и некоторые другие параметры. моя бизнес-логика и требования заставляют меня передавать URL-адрес, а не идентификатор в методе УДАЛЕНИЯ.

Итак, после прочтения я нахожу также некоторый метод удаления и установки блокировки прокси-сервера. а также HTML-форма поддерживает только метод GET и POST.

Я начинаю думать, что лучше использовать только GET и POST в моем REST API. таким образом, я могу опубликовать СООБЩЕНИЕ пользователя для удаления и объекта или ресурса следующим образом:

POST /content/delete/url
Body :
    url : xxxx
    param1 : xxxx
    param2 : xxx

Но в "Своде правил проектирования REST API, О'Рейли", страница 18 сказал

"Методы HTTP-запроса следует использовать, чтобы указать, какая функция CRUD выполняется"

Следующие анти-шаблоны иллюстрируют, чего не следует делать: 

GET /deleteUser?id=1234
GET /deleteUser/1234
POST /users/1234/delete

После поиска и повторного чтения я пришел к некоторому решению

  1. Использование X-HTTP-Method-Override

  2. Используя имя метода api, такое как flicker(api.flickr.com/services/rest/?method=flickr.collections.getInfo) и mailchimp(api.mailchimp.com/1.3/?method=campaignDelete)

Я думаю, что мне нравится решение 1, использовать "Переопределение метода X-HTTP". Что ты думаешь?

Google, похоже, использует переопределение X-HTTP-метода, обратитесь к этому https://developers.google.com/gdata/docs/2.0/basics

Мерцание и Mailchimp используют имя метода, как в решении 2

Author: Ahmad, 2013-01-14
Source

3 answers

Я знаю, что это часть вашей бизнес-логики, но я бы рекомендовал вам переосмыслить ее или, возможно, попробовать использовать другое решение вместо ОТДЫХА.

Делая вещи, подобные тем, о которых вы упомянули, вы нарушите все остальные концепции и все равно не сделаете что-то достаточно хорошее в своем приложении.

Я думаю, что лучшим решением в вашем случае было бы подумать о вашей бизнес-логике. Может быть, это можно сделать без перерыва на ОТДЫХ.

Если вы думаете, что это невозможно сделать, то я бы рекомендовал первое решение, которое вы перечислили. Это кажется менее неправильным.

Надеюсь, это поможет.

 0
Author: Paulo Henrique, 2013-01-14 18:59:24

Вы НЕ МОЖЕТЕ отправить тело с запросом на удаление. и это не имеет смысла!

Спокойным было бы

DELETE  http://www.plocal:3000/api/v1/content/page-1
DELETE  http://www.plocal:3000/api/v1/content/info-page
DELETE  http://www.plocal:3000/api/v1/content/1
DELETE  http://www.plocal:3000/api/v1/content/2

Тестовый вызов с 

curl -v http://www.plocal:3000/api/v1/content -X DELETE
 0
Author: huan son, 2013-01-14 16:56:55

Является ли URL-адрес идентифицирующей информацией элемента содержимого, подлежащего удалению? Если это так,

DELETE https://api.example.com/content/:id

И включите URL-адрес как часть идентификатора. Идентификаторы не обязательно должны быть строго целыми числами.

Вы также можете создать новый маршрут

resources :content, :except => [:delete] do
  member do
    delete delete_by_url
  end
end

И тогда у вас будет новый маршрут удаления с более подходящим именем и конкретным действием в контроллере.

DELETE https://api.example.com/content/:id/delete_by_url
 0
Author: Mark Swardstrom, 2013-01-14 18:21:54