REST URI modelli per le operazioni di query e di comando

Question

Abbiamo un'applicazione che è diviso in due parti:

1. Admin - Dove i dati vengono modificati
2. pubblico - dove i dati vengono letti

I Sto cercando di creare un'API REST per fornire questa funzionalità. È molto facile vedere come le operazioni CRUD possono essere rappresentate, ma non sono sicuro di operazioni specifiche (comandi) su una singola risorsa. Ad esempio per "Pubblica" a Project inviamo un "PublishCommand". Non è possibile ripristinare l'intero Project sul server con la proprietà Published impostata su true.

In una nota simile, sono un po 'confuso su come dovremmo rappresentare operazioni di query più avanzate sulle risorse senza essere classificate come servizio di tipo RPC.

Di seguito sono elencati i modelli di URI per la mia risorsa Project. Sono sulla strada giusta per creare una vera API RESTful?

ADMIN API 
--------- 

// Project Resources 
GET /projects -- get all projects 
POST /projects -- create a new project 

// Project Resource 
GET /projects/10 -- get project with id 10 
PUT /projects/10 -- update project with id 10 
DELETE /projects/10 -- delete project with id 10 

// Project Resource Operations 
POST: /projects/10/publish -- publish project with id 10 
POST: /projects/10/unpublish -- unpublish project with id 10 
POST: /projects/10/setposition/2 -- move to position 2 in projects list 

// Project Sub resources (identity is local to project) 
POST: /projects/10/media -- adds media to project with id 10 
PUT: /projects/10/media/5 -- updates media id 5 for project id 10 
DELETE: /projects/10/media/5 -- deletes media id 5 from project id 10 

PUBLIC API 
---------- 

GET: /projects -- gets all projects (with default limit e.g. first 10) 
GET: /projects?skip=10&take=10 -- gets projects 11 to 20 
GET: /projects/tagged/rest OR /taggedprojects/rest -- gets projects tagged with "REST" 
GET: /projects?orderbydesc=publishdate OR /latestprojects -- gets latest projects 

GET: /projects/10 -- gets project with id 10 

Answer 1

Non penso che REST sia destinato a rappresentare solo le operazioni CRUD. La tua interfaccia mi sta bene e credo che tu sia sulla strada giusta.

C'è un discorso online su DDD e REST: RESTful SOA or Domain-Driven Design - A Compromise? di Vaughn Vernon.

Aggiornamento per includere un commento che ho fatto qui di seguito:

È possibile interrogare yor leggere modello utilizzando GET. Per mutare il tuo dominio puoi PUT o POST alle risorse che rappresentano i comandi. Ciò fornirebbe la ricchezza di un modello di dominio oltre il CRUD e continuerà a utilizzare la semantica inerente di HTTP.

Answer 2

Se guardate la pubblicazione come una risorsa, quindi è possibile utilizzare CRUD (POST/GET/PUT/DELETE):

• POST per creare una pubblicare, passando progetto id
• DELETE per annullare la pubblicazione
• GET per recuperare

questo non significa che il processo deve essere associato con la creazione fisica di record nel database. È solo l'approccio basato sulle risorse che è importante.