Что такое 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?
web-services
rest
MikeWyatt
источник
источник
PATCH /api/car/123и отправить параметр цвета ИЛИ использоватьPUT /api/car/123и отправить весь объект автомобиля. POST будет означать, что вы создаете новую машину и, вероятно, никогда не должны включать идентификатор в конце URL-адресаОтветы:
Подумайте о покупке как о бизнес-субъекте или как о ресурсе в словаре RESTful. При этом покупка фактически создает новый ресурс. Так:
разместит новый заказ. На детали (пользователь, автомобиль и т. Д.) Следует ссылаться по идентификатору (или URI) внутри содержимого, отправляемого на этот адрес.
Неважно, что заказ автомобиля - это не просто ВСТАВИТЬ в базу данных. На самом деле REST не предназначен для отображения таблиц базы данных как операций CRUD. С логической точки зрения вы создаете заказ (покупку), но серверная сторона может выполнять столько шагов обработки, сколько захочет.
Вы даже можете еще больше злоупотреблять протоколом HTTP. Используйте
Locationзаголовок, чтобы вернуть ссылку на вновь созданный заказ, тщательно выбирайте коды ответа HTTP, чтобы информировать пользователей о проблемах (на стороне сервера или на стороне клиента) и т. Д.источник
Насколько я понимаю, способ RESTful заключается в том, что вам не нужны новые HTTP-глаголы, где-то есть существительное, которое будет означать то, что вам нужно делать.
Купите машину? Ну разве не так
источник
На самом деле вы создаете заказ. Поэтому добавьте еще один ресурс для заказа и публикации и поместите его во время процесса заказа.
Думайте о ресурсах, а не о вызовах методов.
Чтобы завершить заказ, вы, вероятно, выполните POST / api / order // complete или что-то подобное.
источник
Я считаю, что REST API помогают гораздо больше, чем просто предоставляют семантику. Поэтому нельзя выбрать стиль RPC только из-за некоторых вызовов, которые кажутся более понятными в стиле работы RPC. Пример - API карт Google для поиска направлений между двумя местами. Выглядит так: http://maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal
Они могли бы назвать это «findDirections» (глагол) и рассматривать его как операцию. Вместо этого они сделали «направление» (существительное) как ресурс и рассматривали поиск направлений как запрос к ресурсу направлений (хотя внутри не могло быть реального ресурса, называемого направлением, и это могло быть реализовано бизнес-логикой для поиска направлений на основе параметров).
источник