plantillas URI REST para operaciones de consulta de comandos y

Question

Tenemos una aplicación que se divide en dos partes:

1. admin - Cuando los datos se cambia
2. Público - Cuando los datos se lee

I Estoy buscando crear una API REST para proporcionar esta funcionalidad. Es muy fácil ver cómo se pueden representar las operaciones CRUD, pero no estoy seguro de las operaciones específicas (comandos) en un recurso individual. Por ejemplo, para "Publicar" un Project enviamos un "Comando de publicación". No PONEMOS el Project completo de vuelta al servidor con su propiedad Published establecida en true.

En una nota similar, estoy un poco confundido sobre cómo deberíamos representar las operaciones de consulta más avanzadas en recursos sin clasificarse como un servicio de tipo RPC.

A continuación he enumerado las plantillas de URI para mi recurso Project. ¿Estoy en el camino correcto para crear una API verdaderamente 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

No creo que REST solo represente operaciones CRUD. Tu interfaz me parece bien, y creo que estás en el camino correcto.

Hay una charla en línea sobre DDD y RESTO: RESTful SOA or Domain-Driven Design - A Compromise? de Vaughn Vernon.

actualización para incluir un comentario que hice a continuación:

Puede consultar yor leer modelo utilizando GET. Para mutar su dominio, puede PONER o PUBLICAR a recursos que representan comandos. Esto proporcionaría la riqueza de un modelo de dominio más allá de CRUD y aún usaría la semántica inherente de HTTP.

Answer 2

Si nos fijamos en la publicación como un recurso, entonces se puede usar CRUD (POST/GET/PUT/DELETE):

• POST para crear una publican, pasando Identificación del proyecto
• BORRAR anular la publicación
• GET para recuperar

Esto no significa que el proceso tiene que estar asociado con la creación física de los registros en la base de datos. Es solo el enfoque basado en recursos que es importante.