Не-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?

Подумайте про придбання як суб’єкт господарювання чи ресурс у словнику RESTful. За словами, покупка - це фактично створення нового ресурсу. Так:

POST /api/purchase

оформить нове замовлення. Дані (користувач, автомобіль тощо) повинні посилатися на id (або URI) всередині вмісту, надісланого на цю адресу.

Не має значення, що замовлення автомобіля - це не просто ВСТАНОВЛЕННЯ в базі даних. Власне, REST не полягає у викритті таблиць вашої бази даних як операціях CRUD. З логічної точки зору ви створюєте замовлення (покупку), але сторона сервера вільна зробити стільки кроків обробки, скільки хоче.

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

НАЙКРАЩИЙ спосіб, наскільки я розумію, це те, що вам не потрібні нові дієслова HTTP, десь є іменник, який буде означати, що вам потрібно зробити.

Придбати машину? Ну не це

POST /api/order

Те, що ви насправді робите, - це створення замовлення. Тож додайте ще один ресурс для замовлення та публікації та поставте його під час процесу замовлення.

Подумайте з точки зору ресурсів, а не з викликів методів.

Для завершення замовлення ви, ймовірно, POST / api / order // завершуєте чи щось подібне.

Я думаю, що API REST допомагають набагато більше способів, ніж просто надання семантики. Тому не можна вибирати стиль RPC лише через деякі дзвінки, які, здається, мають більше сенсу в стилі роботи RPC. Прикладом є програми Google Maps api, щоб знайти напрямки між двома місцями. Виглядає так: http://maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal

Вони могли назвати це "findDirections" (дієсловом) і трактували це як операцію. Швидше вони робили "направлення" (іменник) як ресурс і трактували пошук напрямів як запит на ресурс напрямків (Хоча внутрішньо не могло бути реального ресурсу, який називається напрямом, і його можна було реалізувати за допомогою бізнес-логіки для пошуку напрямків на основі парам).