Не-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 для нового цвета.

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

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

4 ответов


думал о купить как субъект бизнеса или ресурс В словаре RESTful. Тем не менее, покупка фактически создает новый ресурс. Итак:

POST /api/purchase

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

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

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


купить автомобиль? Ну разве это не

POST /api/order

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

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

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


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

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