Home/ Questions/Q 243001
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T20:53:05+00:00

So… I’ve been reading about REST a little bit, and the idea behind it

  • 0

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 webpage?

For example, a user creates some sort of item, a blog post or what have you, and now he wants to delete it, so he clicks a ‘delete’ link on the page. Now what? How do we issue a DELETE request to, say, http://mysite.com/posts/5? And how do we handle that request? I have no experience with cURL or anything, but from the looks of it, I would have to curl_init('http://mysite.com/posts/5') and then work some magic. But where would I even put that script? That would have to be on another page, which would break the whole idea of REST. Then I would just be GETing another page, which would in turn DELETE the page I originally intended?

Is this why people rarely use REST or is there actually a nice way to do this?

Looks like I need to clarify. People are suggesting I include words like “DELETE” and “POST” in the URL. I believe REST dictates that we have a unique URL for each resource but not for each action on that resource. I assume this also means that we only have one and only one URL for each resource. i.e. I want to be able to DELETE or VIEW the contents of a particular post from one URL (by sending either DELETE, PUT, POST, or GET), not different URLs with additional params

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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