Правильное соглашение RESTful URL для вызовов службы приложений? - PullRequest
Новая
       5

Правильное соглашение RESTful URL для вызовов службы приложений?

4 голосов
/ 28 марта 2012

Я видел множество примеров того, как структурировать URL-адреса для базовых операций CRUD, но видел очень мало, когда говорил о дополнительных командных операциях или вызовах службы приложений.

Например, скажем, в моемПрикладная служба У меня есть вызов типа RemoveOldOrders (int customerId), который удалит любой заказ из системы старше 2 лет для клиента с идентификатором «customerId».Как бы выглядел этот URL на моем сервисе отдыха?Как бы выглядела полезная нагрузка вызова?Какой метод HTTP (POST?) Я бы использовал?

Я думал, что это будет примерно так:

/ Customer / 1 / RemoveOldOrders как POST, с пустым телом (какcustomerID будет получен из URL).

Есть ли хорошие рекомендации по этому вопросу?

Обновление: мне кажется, что мне нужно немного прояснить свой вопрос вместо комментария о возможномповторяющийся пост (да, этот пост, по сути, спрашивает об одном и том же, но я не совсем уверен, что на вопрос был получен хороший ответ).

Что если я хочу выполнить операцию с ресурсом, но эта операция невписывается в стандартные HTTP-глаголы?

Другой пример: мое приложение подключено к ESB, и должен быть способ принудительно проецировать мой ресурс на ESB для обработки?В моем текущем веб-сервисе на основе SOAP у меня был бы такой метод: 

ExportCustomer(int customerId)

Теперь, в случае службы RESTful, как я мог бы представить это действие в URI?Вариант 1 из ответа Брайана Келли кажется наиболее логичным, что-то вроде: 

POST http://someapp/api/customer/1/export

или будет: 

POST http://someapi/api/customer/export/1

лучше?

Ответы [ 3 ]

2 голосов
/ 28 марта 2012

Каждый раз, когда вы хотите смоделировать глаголы типа «удалить», вам следует подумать о DELETE.Аналогично, для «создания» подумайте POST (и / или, возможно, PUT), для «чтения» подумайте GET и для «обновления» подумайте PUT (или, возможно, PATCH).* Таким образом, для вашего примера «удалить старые заказы», ​​вы обязательно должны использовать DELETE.Теперь ваша единственная оставшаяся проблема - как определить заказы, которые должны быть удалены.Как только вы это поймете, схема URI станет для нее на месте.

Вот несколько вариантов:

  1. DELETE http://your-api.com/old-orders

    Здесь,значение и диапазон old-orders будет определяться сервером, получающим этот запрос.Это освобождает клиента от необходимости делать это, но лишает его возможности изменять этот диапазон.

  2. GET http://your-api.com/order-query?days-older-than=730

    Возвращает Location URI http://your-api.com/order-query-result/{some ID} это представляет набор старых назначений.Затем вы можете просто выполнить команду DELETE для этого URI, чтобы очистить старые записи одним махом.

  3. Вместо того, чтобы заставлять клиента не забывать вводить команды удаления этого типа, предложите какое-торесурса configuration, которым можно манипулировать через ваш API, чтобы установить какое-то поле, например purgeRecordsOlderThanDays=730, и просто позволить серверу делать это автоматически для вас cron -подобным образом.Это был бы мой предпочтительный подход.

0 голосов
/ 09 сентября 2014

Например, скажем, в моей службе приложений у меня есть вызов типа RemoveOldOrders (int customerId), который удалит любой заказ из системы старше 2 лет для клиента с идентификатором "customerId".Как бы выглядел этот URL на моем сервисе отдыха?Как бы выглядела полезная нагрузка вызова?Какой метод HTTP (POST?) Я бы использовал? 

RemoveOldOrders(int customerId)
DELETE /oldOrders {customerId: id}
DELETE /customer/{id}/orders?old=true
etc...

Вы должны прочитать больше о единообразных идентификаторах интерфейса / ресурса и спецификации метода HTTP .

URL не имеет большого значения.Важно то, что у вас должен быть ресурс с идентификаторами ресурсов (URL), и вы должны манипулировать ими, используя унифицированный (стандартный) интерфейс, например, вызов методов HTTP.

0 голосов
/ 04 декабря 2012

Для экспорта необходимо удалить глагол «экспорт» и заменить его представлением ресурса в ESB: -

  • GET http://someapp/customer/{id}
  • Ответ содержит ссылку на экспорт: GET http://someapp/customer/{id}/ESB
  • При переходе по ссылке экспорта возвращается представление ESB (с соответствующим типом содержимого)
...