90

I'm trying to find some info on the best and most common RESTful url actions.

for example, what url do you use for displaying the details of an item, for editing the item, updating, etc.

/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list   (lists the questions)

hmm. thanks to anyone helping out :)

superjos
  • 12,189
  • 6
  • 89
  • 134
Pure.Krome
  • 84,693
  • 113
  • 396
  • 647

5 Answers5

179

Use URLs to specify your objects, not your actions:

Note what you first mentioned is not RESTful:

/questions/show/<whatever>

Instead, you should use your URLs to specify your objects:

/questions/<question>

Then you perform one of the below operations on that resource.


GET:

Used to obtain a resource, query a list of resources, and also to query read-only information on a resource.

To obtain a question resource:

GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com

To list all question resources:

GET /questions HTTP/1.1
Host: whateverblahblah.com

POST:

Used to create a resource.

Note that the following is an error:

POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

If the URL is not yet created, you should not be using POST to create it while specifying the name. This should result in a resource not found error because does not exist yet. You should PUT the resource on the server first. You could argue that by creating a new question, you are also updating the /questions resource as it would now return one more question in its list of questions.

You should do something like this to create a resource using POST:

POST /questions HTTP/1.1
Host: whateverblahblah.com

Note that in this case the resource name is not specified, the new objects URL path would be returned to you.

DELETE:

Used to delete the resource.

DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com

PUT:

Used to create a resource, or overwrite it, while you specify the resources URL.

For a new resource:

PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

To overwrite an existing resource:

PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com

...Yes, they are the same. PUT is often described as the 'edit' method, as by replacing the entire resource with a slightly altered version, you have edited what clients will GET when they next do.


Using REST in HTML forms:

The HTML5 spec defines GET and POST for the form element.

The method content attribute is an enumerated attribute with the following keywords and states:

  • The keyword GET, mapping to the state GET, indicating the HTTP GET method.
  • The keyword POST, mapping to the state POST, indicating the HTTP POST method.

Technically, the HTTP specification does not limit you to only those methods. You are technically free to add any methods you want, in practice though, this is not a good idea. The idea is that everyone knows that you use GET to read the data, so it will confuse matters if you decide to instead use READ. That said...

PATCH:

This is a method that was defined in a formal RFC. It is designed to used for when you wish to send just a partial modification to a resource, it would be used much like PUT:

PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

The difference is PUT has to send the entire resource, no matter how big it is compared to what's actually changed, whilst PATCH you can send just the changes.

Brian R. Bondy
  • 339,232
  • 124
  • 596
  • 636
  • Hi Brian .. the more i read this, the more it makes sence. I'm assuming that some browsers (or browser versions) do not support PUT or DELETE? if that's the case, do we use POST instead? – Pure.Krome Nov 02 '08 at 23:43
  • 1
    Hi Pure.Knome; Web browsers support them all, also any HTTP library should support them all as well. – Brian R. Bondy Nov 03 '08 at 00:04
  • 5
    I would recommend buying this book by the way if you want to learn all about REST http://oreilly.com/catalog/9780596529260/ – Brian R. Bondy Nov 03 '08 at 00:04
  • 1
    @Brian: a few more questions about your PUT examples. >> PUT /questions/ Why would you do that, instead of doing >> PUT /questions/ because all the data in the form will be used to create the new resource? (continued next comment)... – Pure.Krome Nov 03 '08 at 04:39
  • .. (continued) .. Also, how can we know what the form action will be, when we don't know what the subject will be (which is part of the form action)? For a PUT (that replaces).. sure .. we already know what resource we want to replace. thoughts? – Pure.Krome Nov 03 '08 at 04:40
  • Re: "PUT /questions/ Why would you do that", because when you PUT something you are specifying the new URL path that you want to create. Yes everything in the body of the HTTP request is your actual resource. A resource can be anything, XML, a picture, a file, ... – Brian R. Bondy Nov 03 '08 at 13:06
  • Sorry don't understand your second question. – Brian R. Bondy Nov 03 '08 at 13:07
  • Pure.Krome is asking about implementation of an HTML form - what would the valur of the action attribute be before it is known? Note, though, that only "POST" and "GET" are valid in a form's method attribute, so can this general method be implemented in a web app? – Bobby Jack Nov 04 '08 at 23:41
  • @ Bobby - correct!! .. and look a few comments above... Brian said that web browsers support them ... so i'm assuming that means u can have a method="PUT". I personally want to do this, but don't want to break the standard, so i'm going to see if i can use POST. i've yet to try both. – Pure.Krome Nov 05 '08 at 00:13
  • According to this part (http://www.w3.org/TR/html4/interact/forms.html#idx-form-12) of the spec, only GET and POST are valid. – Bobby Jack Nov 05 '08 at 00:35
  • Thanks, Brian. Although, of course, that's a perfectly viable option, I feel that somewhat negates the advantages of REST (simplicity, portability) by adding in a whole AJAX dependency. Any idea WHY browsers don't support DELETE/PUT? – Bobby Jack Nov 05 '08 at 15:50
  • REST is not designed for use directly in HTML forms. It is designed for use as a programming interface. There is no dependency on XmlHTTP, you can tie into REST with any library. – Brian R. Bondy Nov 05 '08 at 17:57
  • Sure, I understand that, it's just a shame such interfaces won't be web-browsable - i.e. if I have a REST interface for a given problem, I'll need to add in extra backend code to handle web-access (e.g. if (PUT || WEB && POST) or something crazy like that). Bit annoying. – Bobby Jack Nov 06 '08 at 16:26
  • correct Bobby -> the fact that the Html spec currently doesn't handle all the HttpVerbs is a massive mistake and oversight. Refer to what Brian said about PUT -> used to create _new_ resources! this is MASSIVE! and the html spec doesn't handle PUT in the form method attribute! Sacrilege! – Pure.Krome Nov 15 '08 at 06:08
  • Hi Bobby Jack and Pure.Knome. I just appended to my answer above with how to use PUT, and DELETE in HTML forms. It seems that the HTML5 spec does have support for all of these verbs. – Brian R. Bondy Nov 15 '08 at 14:35
  • sorry, I am a bit confused, according to http://www.weierophinney.net/matthew/archives/228-Building-RESTful-Services-with-Zend-Framework.html and http://www.xml.com/pub/a/2004/12/01/restful-web.html it says POST is used to create new entity, but you are saying PUT is used instead...? – Jeffrey04 Nov 11 '09 at 02:42
  • Both can be used to create a resource, but PUT would explicitly specify the URL of that resource to be created, whereas POST would specify some base URL and the link would be typically returned to you. – Brian R. Bondy Nov 11 '09 at 03:56
  • 1
    @Brian R. Bondy, Thanks for your great answer. POST request to existing resource is described as "appending" in oreilly's restful book(pg:100,101), contrary to your general "modifying" term. After all, to append is more specific than to modify - which may convey "PUT to an existing resource" - and semantically sounds more correct for POST - adding new resource to the specified link, either by appending to or creating a child resource to that. – Özgür Jun 23 '10 at 11:15
  • It still needs to be answered how one could you express (in a web app) an URL for simply rendering the resource, and another URL for rendering a form for the resource? The original examples are /show and /edit – rvange Jul 04 '14 at 11:30
  • If using to identity the question in URL, how does the client know the next new id is when the id is auto increment for MySQL? – Cloud Jun 03 '18 at 23:24
  • @BrianR.Bondy Why the first approach is not REST, what principle in REST it violates? – adnanmuttaleb Dec 26 '19 at 08:19
11

Assuming /questions/10 is a valid question then the method is used to interact with it.

POST to add to it

PUT to create or replace it

GET to view/query it

and DELETE to well.. delete it.

The url doesn't change.

Özgür
  • 8,077
  • 2
  • 68
  • 66
Allain Lalonde
  • 91,574
  • 70
  • 187
  • 238
  • 4
    Wrong. PUT must be idempotent. You must be able to make the same PUT request many times, with no effect after the first time. So, creating a resource with every PUT request is not idempotent. – aehlke Jul 20 '09 at 17:45
  • 3
    "Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request.", using put at a URI that doesn't currently make a Resource available can create a resouce. Immediately PUTting again would just do it again which would have no effect. In this way you're creating a resource, but the query is still idempotent. If you later come back and wish to change the resource, you man PUT to the same URI with different data (which would be a different request and could itself be repeated any number of times with the same result). – Allain Lalonde Jul 21 '09 at 11:26
  • 1
    Actually, take a look at the answer that received 25 votes above it's stated that PUT can be used to create or replace a resource. – Allain Lalonde Jul 21 '09 at 11:27
  • 3
    Creation only works as long as specifying the ID of a new resource is allowed. While the is possible, it is more often more convinent for the user to POST to /collection and be returned links that include the new id: – pgraham May 04 '12 at 20:24
  • 2
    @aehIke Creation of a new resource by PUT does not make it non-idempotent since the idea is that if I 'PUT /items/10' and item 10 didn't exist prior, then it will just be created. However if I 'PUT /items/10' again for the second time, well now it already exists so it will just be replaced hence idempotence is preserved since an subsequent PUT requests have no new side effect. (Of course that is assuming that I keep on putting the same exact item each time) – Alappin Jul 23 '15 at 04:29
3

I'm going to go out on a limb and guess that you what you mean is what are standard controllers for MVC when you say "RESTful" urls, since your examples could be considered non-"RESTful" (see this article).

Since Rails really popularized the URL style you seem to be interested in, I offer below the default controller actions produced by the ScaffoldingGenerator in Ruby on Rails. These should be familiar to anyone using a Rails application.

The scaffolded actions and views are: index, list, show, new, create, edit, update, destroy

Typically you would construct this as:

http://application.com/controller/<action>/<id>
tvanfosson
  • 524,688
  • 99
  • 697
  • 795
  • 5
    Out-of-band URI conventions are NOT RESTful. Quoting Fielding himself: "A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations.." – aehlke Jul 20 '09 at 17:46
1

Here is a mapping of your current URLs using the REST principle:

/question/show/<whatever>

If you identify the question as a resource, then it should have a unique URL. Using GET to display it (retrieve it) is the common practice. It becomes:

GET /question/<whatever>

/question/edit/<whatever>

Now you want your user to have another view of the same resource that allows him to edit the resource (maybe with form controls).

Two options here, your application is an application (not a website), then you may be better using JavaScript to transform the resource into an editable resource ono the client side.

If this is a website, then you can use the same URL with additional information to specify another view, the common practice seems to be:

GET /question/<whatever>;edit

/question/update/<whatever> (this is the post back url)

This is to change the question, so PUT is the correct method to use:

PUT /question/<whatever>

/question/list   (lists the questions)

The list of question is actually the parent resource of a question, so it naturally is:

GET /question

Now you may need some more:

POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)

Tada :)

Vincent Robert
  • 35,564
  • 14
  • 82
  • 119
-1

Your four examples could be:

GET /questions/123
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
GET /questions

To add a question:

POST /questions q=What+is+the+meaning+of+life

The server would respond:

200 OK (or 201 Created)
Location: /questions/456
pbreitenbach
  • 11,261
  • 3
  • 33
  • 24