Rest Services conventions

Question

In Rest Services,we normally use 'GET' requests when we want to retrieve some data from the server, however we can also retrieve data using a 'POST' request. We use 'POST' to create, 'PUT' to update, and 'DELETE' to delete, however we can even create new data using a 'DELETE' request.

So I was just wondering what is the real reason behind for that, why these conventions are used?

Answer 1

I recommend reading the spec which clearly states how each each http-method should be used.

why these conventions are used?

They are conventions, that is, best practices that have been adopted as a standard. You do not have to adhere to the standard, but most consumers of a REST service assume you do. That way it is easier to understand the implementation / interface.

Answer 2

So I was just wondering what is the real reason behind for that, why these conventions are used?

So the world doesn't fall apart!

No but seriously, why are any protocols or standards created? Take this historical scenario. Back in the early days of Google, many developers (relative to nowadays) weren't too savvy on the HTTP protocol. What you might've caught was a bunch of sites who just made use of the well known (maybe only known) GET method. So there would be links that would be GET requests, but would perform operations that were meant to be POST request, that would change the state of the server (sometimes very important changes of state). Enter Google, who spends its days crawling the web. So now you have all these links that Google is crawling, all these links that are GET requests, but changing the state of the server. So all these companies are getting a bunch of hits on their servers changing state. They all think they're being attacked! But Google isn't doing anything wrong. HTTP semantics state that GET requests should not have state changing behaviors. It should be a "read only" method. So finally these companies smartened up, and started following HTTP semantics. True story.

The moral of the story: follow protocols, that's what they're there for - to follow.

You seem to be looking at it from the perspective of server implementation. Yeah you can implement your server to accept DELETE request to "get" something. That's not really the matter at hand. When implementing the server, you need to think about what the client expects. I mean ultimately, you are creating an API. Look at it from a code API perspective

public class Foo {

    public Bar bar;

    public Bar deleteBar() {  
        return bar;            // Really?!
    }

    public void getBar() {  
        bar = null;            // What the..??!
    }
}

I don't know how long a developer would last in the game, writing code like that. Any callers expecting to "get" Bar (simply by naming semantics) has another thing coming. Same goes for your REST services. It is ultimately a WEB API, and should follow the semantics of the protocol (namely HTTP) on which it is built. Those who understand the protocol, will have an idea of what the API does (at least in the CRUD sense), simply based on the type of request they make.

My suggestion to you or anyone trying to learn REST, is to get a good handle on HTTP. I would keep the following document handy. Read it once, then keep it as a reference

• Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Answer 3

GET cached by proxies POST and DELETE not!

Yes you can create data with GET but now you have to destroy that cached.Why to do extra job.

Also maximum header sizes accepted are different because of purpose of usage.