Designing a RESTful website [closed]

问题

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

I am trying to learn to create RESTful web applications. I have a few doubts.

1. Say, I have a requirement to display the name of user on the website header. I used to do it by storing the user object in session and then fetching the name in the JSP. But now, isn't that storing a conversational data and breaking REST convention? Do I have to send the name to the client in every response as long as the user is logged in (overkill)?
2. I have seen URLs in many websites including SO in the pattern questions/4135336/correct-rest-uri-design. Wouldn't questions/4135336 suffice, assuming 4135336 is the ID? Then what is that comes after that? another id? any standard to generate it?
3. I have read that for a particular resource, say /students/{student} CRUD operations should be done using GET (fetch), POST (update), PUT (create/overwrite) ,DELETE (delete). If its an application read by a human, do we need these conventions. For eg: Wouldn't a POST do a delete by sending appropriate params? what are we trying to achieve?

Thanks in advance :)

回答1:

The whole idea behind REST is that each request is completely independent from any other from the server's perspective. The client is responsible for maintaining state, if any. For a given request, the server transfers information to the client needed to satisfy the request, and may also transfer information which allows the client to be able to find additional information by making more requests. With that in mind:

1. This sort of depends on the design of your site, and what is considered to be a "resource". If the client requests a page, and that page is treated as a single resource unit, then yes, the server would need to return the user name as part of the response for any request. If the design is such that the client can ask for things in pieces, then it would be the client responsibility to ask for the user name in a request, then render it in the header. The content of the rest of the page would be rendered with additional separate requests.
2. The ID is sufficient. The remainder of the URL is there only for readability for humans, since humans don't easily remember that "415336" is the ID for an article titled "Correct Rest Uri Design". This extra information in the URL is not used by the server to look up the item; only the ID is used. As such it is not really part of REST per se, it is just a nicety provided by the site.
3. REST is ideally supposed to be client agnostic; in theory, you could write a generic REST client which can navigate any server supporting REST, and that client would be able to discover what resources are on the server and be able to manipulate them. This is possible because REST takes advantage of the standard vocabulary of HTTP verbs to represent the common CRUD operations, as you pointed out. If you overload the HTTP verbs to mean other things, then a generic client might not be able to navigate the site. Moreover, if you overload GET to have side effects such as updating or deleting information, then a generic client (think a web crawler) could end up destroying information just by trying to find out what is available on the site. This is never a good idea.

回答2:

In response to No. 3: The rule of thumb says you should present data with GET and manipulate data with POST. Creating and deleting as such have no need to be anything other than POST.

Never manipulate data with GET though, otherwise your links (somesite.com/users/delete?user=1) could become indexed and your entire database will become messed up. Using GET for presenting data also allows your users to bookmark a specific result and provide a link to send to others.

回答3:

For number 3, you ask what are we trying to achieve by using http methods (other than the most generic). What we achieve is optimisation potential.

the most generic method is POST. post can do anything, including retrieve read only content. to optimise that, we created GET. GET results can be cached because the are the same for everyone, and multiple GET requests always gives the same result (for static files, non-static files the server has to tell caches how long they are valid for).

we can further tease out other use cases that can be optimised, for example if you want to delete a specific object, use the DELETE method. if the server doesn't respond, you can try again without fear because if the object is gone, your request can be ignored, and if the object didn't get deleted the first time, it will on the second attempt. you can't know that if the delete request is wrapped in a generic envelope, for which the client does not know the semantics (such as a html form).

来源：https://stackoverflow.com/questions/16760956/designing-a-restful-website