什么是最好的/常见的 RESTful url 动词和动作？

小开

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.

小开

最佳答案

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.

小开

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>

小开

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 :)

小开

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