Операции без CRUD в службе RESTful

Каков способ "RESTful" добавления операций, не связанных с CRUD, в службу RESTful? Скажем, у меня есть служба, которая позволяет CRUD доступ к таким записям:

GET /api/car/123           <- Returns information for the Car object with ID 123
POST /api/car              <- Creates a new car (with properties in the request)
PUT /api/car/123           <- Updates car 123 (with properties in the request)
DELETE /api/car/123        <- Deletes car 123    
POST /api/car/123/wheel/   <- Creates a wheel and associates it to car 123

Если я хочу изменить цвет автомобиля, я бы просто POST /api/car/123 и включил переменную POST для нового цвета.

Но позвольте сказать, что я хочу купить автомобиль, и эта операция сложнее, чем просто обновление "пользовательской" записи "принадлежащей машине" собственности. Является ли RESTful просто чем-то вроде POST /api/car/123/purchase, где "покупка" по сути является именем метода? Или я должен использовать собственный HTTP-глагол, например PURCHASE вместо POST?

Или операции, отличные от CRUD, полностью выходят за рамки REST?

ОТВЕТЫ

Ответ 1

Подумайте о покупке как бизнес-сущности или ресурсе в словаре RESTful. При этом покупка покупки фактически создает новый ресурс. Итак:

POST /api/purchase

разместит новый заказ. Детали (пользователь, автомобиль и т.д.) Должны ссылаться на идентификатор (или URI) внутри содержимого, отправленного на этот адрес.

Не имеет значения, что заказ автомобиля - это не просто простой INSERT в базе данных. На самом деле, REST - это не просмотр ваших таблиц базы данных как операций CRUD. С логической точки зрения вы создаете заказ (покупка), но серверная сторона может выполнять столько шагов обработки, сколько захочет.

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

Ответ 2

RESTful, как я понимаю, это то, что вам не нужны новые HTTP-глаголы, там существительное где-то будет означать, что вам нужно делать.

Купить автомобиль? Ну, это не так.

POST /api/order

Ответ 3

То, что вы действительно делаете, это создать заказ. Поэтому добавьте еще один ресурс для заказа и сообщения и поставьте его во время процесса заказа.

Подумайте о ресурсах, а не о вызовах методов.

Чтобы завершить заказ, вы, вероятно, получите POST/api/order//complete или что-то подобное.

Ответ 4

Я чувствую, что API REST помогает гораздо больше способов, чем просто предоставление семантики. Поэтому нельзя выбирать стиль RPC только из-за некоторых вызовов, которые, похоже, имеют больше смысла в стиле RPC. Например, google maps api, чтобы найти направления между двумя местами. Выглядит так: http://maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal

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