Geek Answers Handbook

In a RESTful application, how can we distinguish between an “action” and an HTTP verb (GET, POST, PUT, DELETE)?

In a RESTful application, can we distinguish between an “action” and an HTTP verb ( GET , POST , PUT , DELETE )?

For example, as I understand it, a GET request to the /products resource should return a list of all products. A POST request /products should create a new product. How does the user request the original form that is used to create the product? My initial answer would be a GET request for the same URI, but as mentioned above, this should return a list of all products, not an empty form for creating the product.

Most of the frameworks I investigated have solved this problem by creating an “action” part of the URI. For example, a POST request to /products/create will create a new product, while a GET request to /products/create will give an empty form for creating a product. For a list of all products, there would be a GET request for /products or /products/get , /products/read , etc. Depending on the structure under consideration. This approach removes the ambiguity above, but it contradicts what I read about traditional REST design.

+4
source share
2 answers

IMHO, the best option is to make the request method a part of the controller action.

Suppose you are accessing http://who.cares/product/42 or http://who.cares/product/42/specification . This request to the web server will be translated as a Product controller. The action name must be created by combining the request method and the command:

 DELETE "http://who.cares/product/42" controller: "Product", action: "deleteProduct()" GET "http://who.cares/product/42/details" controller: "Product", action: "getDetails()" POST "http://who.cares/product/42/review" controller: "Product", action: "postReview()" GET "http://who.cares/products/ controller: "Products", action: "getProducts()" POST "http://who.cares/products/ controller: "Products", action: "postProducts()"
+2
source

here is an example like Rails does

 REST request path | action name | Description ---------------------|-------------------|------------- GET /profile/new | new | Render a form for creating the profile POST /profile | create | Create a the profile from the received data GET /profile | show | Render a the profile GET /profile/edit | edit | Render a form for editing the profile PUT /profile | update | Update the profile based on the received data DELETE /profile | destroy | Destroy the profile

I see no conflict, the idea is this: URLs are human-readable, and you can enter new URIs to display different representations of the same resource. (for example, profile / 1 / edit and profile / 1) / profile / new - the address of the empty profile (for example, profile / 1, profile / 2, etc. in the show method) But if you want, you can assume that profile / 1 / edit is a kind of nested profile resource / 1 / resource, but I like that it's just a different view of profile / 1 / resource =)

It is also nice to use multiple and singular URIs when working with many resources or with one, for example

 /profile/1.html - gives you 1 resource /profiles.html - gives you list of profiles
+1
source

More articles:


All Articles