1

I know Restful Get operation is for retrieving info. And Restful Post is for creating/inserting a resource in which we don't have unique identifier.

But some one just asked me "what are the advantages of Restful GET over Restful POST? what are the advantages in terms of the server side capability?"

Rose
  • 2,792
  • 4
  • 28
  • 42
  • 3
    This has been asked numerous times, [here's](http://stackoverflow.com/q/46585/1101070) one example. – Marvin Pinto Jan 25 '12 at 00:37
  • 1
    Marvin - the link that u gave doesn't precisely address my issue. I'm not asking about Http GET here. Restful Get doesn't necessarily show up on browser's url. And I've emphasized 'server side capability' - pls re-read. – Rose Jan 25 '12 at 01:03
  • 2
    @Rose A GET is a GET. How you 'style' it, using REST or whatever else, doesn't change it under the hood. Server-side capability depends on a lot of factors - particularly the process you are using to handle the requests. You've mentioned nothing about how you are receiving or handling the requests. – Beau Grantham Jan 25 '12 at 01:06

3 Answers3

10

I think the answer "they" want, at least the one I would try, is that GETs are idempotent (make no change to the server) and can be cached for speed and tremendous scalability. Handling lots of GETs is (relatively) easy on the server. A POST creates things on the server, so it changes things, cannot be "cached", is more work, harder to scale. blah blah...

user949300
  • 15,364
  • 7
  • 35
  • 66
  • I agree. Get is idempotent. Post might have server side change per multiple calls. Is this "idempotency" granted by our implementation? meaning if i write a GET method and change x to x++ and save it, it is no more idempotent, right? So is it just the RESTful spec that advises so? or is there any thing given by web frameworks/libs towards making the request idempotent? – Rose Jan 25 '12 at 02:55
  • 4
    @Rose: There is nothing *inherent* within a GET or POST request that makes it idempotent. GET/POST are simply verbs to try and classify the request and allow the server application to enable additional functionality based on that classification; such as processing FORM fields. With that in mind, idempotency comes solely from implementation. By common convention and recommended best practices a GET request should *never* modify data. If you follow this convention/practice then your GET requests will meet the requirements to be idempotent and therefore would be eligible for caching. – NotMe Jan 25 '12 at 15:42
1

There is no difference whatsoever in server-side capability that you don't make yourself. Whether the request was a GET or a POST is nothing but a piece of data on the HttpServletRequest object by the time it gets to you. You could handle them completely differently, or with the exact same code.

Affe
  • 47,174
  • 11
  • 83
  • 83
  • 2
    While you can code anything the way you want, the HTTP spec clearly states that GET must not have side effects. These are semantics that are shared between clients, proxy servers and servers. Limiting yourself to think of a request only in terms of server-side implementation doesn't make sense in a network protocol. – Bruno Jan 25 '12 at 02:43
  • I agree with you, that's just not how I interpreted the question as stated by OP asked :) – Affe Jan 25 '12 at 02:47
1

You can use GET or POST to do anything you want. If you deviate from the HTTP Standard then you are going to have to explain that to you consumers and you've completely undermined REST principles. An example of this is when websites used the GET to delete resources. Then when Google started crawling the site it stated deleting resources. GET is supposed to be idempotent so this wouldn't have happened if the service creators followed the HTTP Spec.

suing
  • 2,808
  • 2
  • 16
  • 18