Operações não CRUD em um serviço RESTful

Qual é a maneira "RESTful" de adicionar operações não CRUD a um serviço RESTful? Digamos que eu tenha um serviço que permite o acesso CRUD a registros como este:

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

Se eu quiser mudar a cor do carro, eu simplesmente POST /api/car/123 incluiria uma variável POST para a nova cor.

Mas digamos que eu queira comprar um carro e essa operação seja mais complicada do que simplesmente atualizar a propriedade de "carro de propriedade" de um registro do "usuário". É RESTful simplesmente fazer algo como POST /api/car/123/purchase, onde "compra" é essencialmente um nome de método? Ou devo usar um verbo HTTP personalizado, como em PURCHASEvez dePOST ?

Ou as operações não CRUD estão completamente fora do escopo do REST?

Pense na compra como uma entidade comercial ou um recurso no dicionário RESTful. Dito isso, fazer uma compra é, na verdade, criar um novo recurso. Assim:

POST /api/purchase

fará um novo pedido. Os dados (usuário, carro, etc.) devem ser referenciados por id (ou URI) dentro do conteúdo enviado para este endereço.

Não importa que encomendar um carro não seja apenas um simples INSERT no banco de dados. Na verdade, REST não é expor suas tabelas de banco de dados como operações CRUD. Do ponto de vista lógico, você está criando um pedido (compra), mas o lado do servidor está livre para executar quantas etapas de processamento desejar.

Você pode até abusar ainda mais do protocolo HTTP. Use o Locationcabeçalho para retornar um link para o pedido recém-criado, escolha cuidadosamente os códigos de resposta HTTP para informar os usuários sobre os problemas (servidor ou cliente), etc.

Pelo que entendi, a maneira RESTful é que você não precisa de novos verbos HTTP, há um substantivo em algum lugar que significará o que você precisa fazer.

Comprar um carro? Bem não é isso

POST /api/order

O que você realmente está fazendo é criar um pedido. Portanto, adicione outro recurso para pedido e postagem e coloque lá durante o processo de pedido.

Pense em termos de recursos, em vez de chamadas de método.

Para finalizar o pedido, você provavelmente POSTAR / api / pedido // concluir ou algo semelhante.

Acho que as APIs REST ajudam de muito mais maneiras do que apenas fornecendo semântica. Portanto, não é possível escolher o estilo RPC apenas por causa de algumas chamadas que parecem fazer mais sentido no estilo de operação RPC. Exemplo é a API do google maps para encontrar direções entre dois lugares. Tem a seguinte aparência: http://maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal

Eles poderiam ter chamado de "findDirections" (verbo) e tratado como uma operação. Em vez disso, eles fizeram "direção" (substantivo) como um recurso e trataram a localização de direções como uma consulta no recurso de direções (embora internamente não pudesse haver nenhum recurso real chamado direção e ele pudesse ser implementado pela lógica de negócios para encontrar direções com base em parâmetros).