The RESTful flow?

前端 未结 8 1254
傲寒
傲寒 2021-01-16 06:34

So...

I\'ve been reading about REST a little bit, and the idea behind it sounds nice, but the question is, can it be easily integrated into the standard flow of a we

相关标签:
8条回答
  • 2021-01-16 07:05

    Another way of doing it, assuming a webbased/webapplication-based request, is have 2 submitbuttons. Since PUT and DELETE use the same uri/url. You could add a specific delete form and attach a specific name to this delete-button, so when this is sent via a post, you can use this button-name to turn the action into a DELETE

    0 讨论(0)
  • 2021-01-16 07:07

    Well one way is to make an AJAX call using the DELETE method.

    0 讨论(0)
  • 2021-01-16 07:09

    Facebook's REST server is a pseudo one, you can do it like them, asking for the post method: POST, GET, etc. the action and the other values you need for that request.

    Why I say facebook is a pseudo REST server? : well, one of the Principles of REST says

    • Every resource is uniquely addressable using a universal syntax for use in hypermedia links

    in facebook you only have /server.php and there is where you make the request, even for (POST, GET, PUT, DELETE...)

    the other way is using mod_rewrite and parse the url the client is requesting

    EDIT: just found this, looks interesting. Have fun!

    0 讨论(0)
  • 2021-01-16 07:10

    With a restful server, the same url (say /books/1) can respond to many different verbs. Those verbs, GET, POST, PUT, and DELETE, together with the path, indicate what you want to do to the data on the server. The response tells you the answer to your request.

    REST is about accessing data in a predictable and sensible way.

    If you come from a strong PHP background, where every url has to map to a particular file, you're right, it doesn't really make sense. The two most visible RESTful development environments, ASP.NET MVC and Rails, each have special servers (or server logic) which read the verbs and do that special routing for you. That's what lets the "normal flow" of the application go through as you'd expect. For PHP, there are frameworks that help with this, such as WSO2's WSF.

    How REST works with Web Browsers

    Take, for instance, your example. We have posts, and we want to delete one.

    1. We start by visiting a url like /posts/4. As we would expect, this shows post 4, its attributes, and some actions you could take on it. The request to render this url would look like GET /posts/4. The response contains HTML that describes the item.

    2. The user clicks the "Delete Item 4" link, part of the HTML. This sends a request like DELETE /posts/4 to the server. Notice, this has re-used the /posts/4 url, but the logic must be different.

      Of HTML forms and web browsers, many of them will change a link with method="delete" into a method="post" link by default. You will need to use Javascript (something like this) to change the verb. Ruby on Rails uses a hidden input field (_method) to indicate which method is to be used on a form, as an alternative.

    3. On the server side, the "delete an item" logic is executed. It knows to execute this because of the verb in the request (DELETE), which matches the action being performed. That's a key point of REST, that the HTTP verbs become meaningful.

    4. After deleting the item, you could respond with a page like "yep, done," or "no, sorry, you can't do that," but for a browser it makes more sense to put you somewhere else. The item being deleted, responding with a redirect to GET /posts makes good sense.

    If you look at the server log, it will be very clear what everybody did to the server, but that's not as important as...

    How REST works with Arbitrary Data

    Another key point of REST is that it works well with multiple data formats. Suppose you were writing a program that wanted to read and interact with the blog programmatically. You might want all the posts given in XML, rather than having to scrape the HTML for information.

    GET /posts/4.xml is intuitive: "Server, please give me xml describing post #4." The response will be that xml. A RESTful server makes it obvious how to get the information you want.

    When you made the DELETE /posts/4.xml request, you're asking, "Server, please delete item #4." A response like, "Okay, sure," is usually sufficient to express what's happened. The program can then decide what else it wants and make another request.

    0 讨论(0)
  • 2021-01-16 07:12

    Don't overthink it. You're not going to be able to do this with straight HTML forms and a browser. They do not support DELETE method. Ajax can do it.

    I want to be able to DELETE to VIEW the contents of a particular post from one URL (by sending either DELETE, PUT, POST, or GET), not different URLs with additional params

    Delete to view? I'm not sure I understand it, but your delete should be done through the headers, not through the URL. The delete method should not return a view. REST is a service, not all requests are meant for visual consumption.

    0 讨论(0)
  • 2021-01-16 07:13

    Depending on what framework you use, there are models that determine how actions are handled for each resource.

    Basically using another parameter, you want to send the resource what action to perform. That parameter may be sent through AJAX/JS for example.

    If you want to do it without javascript/ajax (in case it's disabled), then a form POST method would work as well, sending the resource the extra ACTION parameter.

    Of course, in both cases, you have to consider security, and make sure that they're not sending the resource an action they shouldn't be. Make sure to do your checking on the backend, and send an appropriate response or error message.

    Client side scripting, whether through JS/Ajax or form POST or other methods require the extra security precaution.

    Edited after clarification from poster.

    0 讨论(0)
提交回复
热议问题