All geek questions in one place

REST URI patterns for query and command operations

We have an application that is divided into two parts:

  • Admin - where the data is changed
  • Publish where data is read

I am looking to create a REST API to provide this function. It is very easy to see how CRUD operations can be represented, but I'm not sure about the specific operations (commands) on a separate resource. For example, to "Publish" a Project , we send out "PublishCommand". We do not drag the full Project back to the server with the Published property set to true .

At the same time, I got a little confused about how we should represent more complex resource request operations without being classified as a service like RPC.

The following are the URI patterns for my Project resource. Am I on the right track to create a truly RESTful API?

 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 eg 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
+6
source share
2 answers

I do not think REST is intended only to represent CRUD operations. Your interface looks good to me, and I believe that you are on the right track.

They talk online about DDD and REST: is RESTful SOA or Domain-Driven Design a compromise? from Vaughn Vernon.

Refresh to include the comment I made below:

You can request a reading model using GET. To change your domain, you can use PUT or POST for resources representing commands. This would ensure the richness of the domain model outside of CRUD and still use the inherent HTTP semantics.

+5
source

If you look at the publication as a resource, you can use CRUD (POST / GET / PUT / DELETE):

  • POST for creating a publication, passing a project identifier
  • DELETE to cancel publication
  • GET to retrieve

This does not mean that the process should be associated with the physical creation of records in the database. This is an important resource approach .

+2
source

Source: https://habr.com/ru/post/920802/

More articles:


All Articles