1

I have read several sources about HTTP methods, but I still don't understand clearly the simplest thing: what are they for?

Each source I've seen points out when particular methods should be used, but what does it change in practice? Is there any difference how the request is being handled between, let's say, GET and POST?

Or maybe those methods are there to allow us to handle multiple behaviors on one URL?

And finally, what about the browsers? Forms can only make GET and POST requests and they handle them in different way. POST form sends data "in the background", while GET passes them in the URL. Does it have anything to do with the protocol or is it just browsers' convention?

Thank you in advance for clarifying it for me. :)

Robo Robok
  • 21,132
  • 17
  • 68
  • 126

1 Answers1

3

Fundamentally, yes, methods are there to allow different "interactions" with every "entity". HTTP is designed so you can think of each URL as one entity.

  • /users represents all users
  • /users/dave represents one specific user
  • POST /users lets you create a new user
  • PUT /users/dave lets you modify a specific user
  • GET /users gets you a list of users
  • GET /users?name=dave lets you query for a list of users named "dave"

and so on...

That's the way HTTP was designed to be used, each verb has a specific implied meaning. You can use those verbs any way you want really, but GET implies "passive" information retrieval, while POST, PUT and DELETE imply destructive changes.

Browsers and other clients do handle these differently. It's expected that anything GET can be requested at any time any number of times, can be cached, can be pre-fetched, can be queried mostly out of order. More destructive actions should be performed only once when requested and not cached, pre-fetched or anything else. A browser will explicitly ask for confirmation if you're "reloading" a page requested via POST.

POST form sends data "in the background", while GET passes them in the URL. Does it have anything to do with the protocol or is it just browsers' convention?

"In the background" is the wrong way of thinking. The difference is between the URL and the request body. A GET request should not/must not have anything in its request body. Again, it's only passive information retrieval and must solely consist of HTTP headers. A POST request can have a request body. A request can have "data" both in its URL and in its body. Again, an assumption is that GET URLs can be shared and passed around, since it just links to information. POST requests on the other hand need to be very deliberate, so its information should not and doesn't need to be in the URL.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • I used HTTP in web browsers most of my life, so perhaps my understanding of HTTP protocol is spoiled. Webpages tend to have different URLs for each action, like /users/edit, users/delete etc. That's what I always thought - you want to do something different, change URL. But I'm aware that it's for separate admin pages, which are all requested with `GET`. Forms actions are most of the time pointed to the same URL. Can I assume that this is all against valid HTTP usage? – Robo Robok Feb 16 '15 at 02:01
  • Plus, there are plenty APIs that follow that convention as well. For example, deleting things don't use `DELETE` method on `/users/dave`, but something like `/users/delete/dave`. Is that wrong? – Robo Robok Feb 16 '15 at 02:03
  • There are two issues here: 1) If you'd be interacting with an API solely through HTTP, there'd be no need for `/users/dave/edit`. You'd just `PUT /users/dave` with all the data in the request body. Of course, nobody really writes HTTP requests by hand. This only really works for RESTful API interactions these days. `/users/dave/edit` is necessary to *serve an interface* for you to fill in that data. 2) Browsers traditionally only support `GET` and `POST`, but none of the other methods. This is mostly an unfortunate shortcoming in the implementation. – deceze Feb 16 '15 at 02:06
  • Since the advent of SPAs (single page applications) which have all the views on the client in Javascript and really do just have a RESTful API on the server, the "proper" usage of HTTP has become more of a reality than before. – deceze Feb 16 '15 at 02:08
  • Yes, this is the kind of application I'm creating now and I want to make my RESTful API as "valid" as possible. Please let me know two last things. 1) Why do most RESTful APIs over there stick to GET and POST methods and change their URLs? 2) How to know when should I include something in the URL and when in the request body? My understanding is, the URL should always reflect the entity that I'm working on. So if I'm adding user, the entity is the group of users, so `/users`. If I want to delete particular user, I'm working on him, so it's `/users/dave`. Am I right? – Robo Robok Feb 16 '15 at 02:17
  • 1
    Right. Maybe as a rule of thumb, try to keep your URLs so that any ordinary `GET` request on them would make sense. You can `POST /users/dave` with data in the body, but you can also simply `GET /users/dave`. `/users/dave` is one entity you can do different things to. "Modifiers" to these actions should be put into query parameters, e.g. `GET /users/dave?profile=full`. These do not necessarily need to make sense with other verbs. – deceze Feb 16 '15 at 02:39
  • Thank you so much. Now it makes sense for me. The sources I've seen were way too nerdy and low level to understand them :) – Robo Robok Feb 16 '15 at 02:50