If I'm making a web application which integrates with a server-side backend, would it be considered best practice to use HTTP methods semantically? That is, for example, if I'm fetching data (e.g., to populate a menu, etc.), I would use GET, but to update data (e.g., save a record), I would use POST. (I realise there are other methods that may be even more appropriate, but we need to consider browser support.)

I can see the benefits of this in the sense that it's effectively a RESTful API, but at a slightly increased development cost. In my previous projects, I've POST'd everything: Is it worth switching to a RESTful mindset simply for the sake of best practice?

  • 3
    Note that there are semantic differences between, PUT and POST - PUT is idempotent, POST is not.
    – Joe
    Oct 19, 2012 at 17:19
  • 1
    @Joe Good point: If I were writing a true RESTful API then I would respect this, but as I say, browser support is limited. Oct 19, 2012 at 20:50

2 Answers 2


My answer is simply: yes.

There are cool advantages also, like you can get stuff directly by accessing URLs from different parts of you application. Than when you post things you are covered and you don't expose stuff.

If you respect the verbs in you classes in whatever programming language you use, it will also help to better structure your code. Classes that are sending data will more naturally separate from those which are receiving or searching for information.

  • 1
    Yep. Using GETs for data retrieval means you can bookmark pages or send others links via email/chat/etc. And clicking 'reload' doesnt trigger the annoying 'post again?' message. Honestly, its little things like this that seem trivial that just start feeling "right" when you do them.
    – GHP
    Oct 25, 2012 at 15:19

Another advantage: Using GET (instead of POST for retrieval style requests) means caching is possible.

Also, a down side that might cause problems: Some proxies have patchy DELETE and PUT method support.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.