23

I understand the definition of GET and POST as below.

GET: List the members of the collection, complete with their member URIs for further navigation. For example, list all the cars for sale.

POST: Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually included as part of the data returned by this operation.

MY API searches for some detail in server with huge request payload with JSON Message in that case Which Verb should i use ?

Also can anyone please let me know the length of the characters that can be passed in query string.

Ravi
  • 1,247
  • 4
  • 15
  • 35

5 Answers5

17

The main difference between a GET and POST request is that in the former, the entire request is encoded as part of the URL itself, whereas in the latter, parameters are sent after the header. In addition, in GET request, different browsers will impose different limits on how big the URL can be. Most modern browsers will allow at least 200KB, however Internet Explorer seems to limit the URL size to 2KB.

That being said, if you have any suspicion that you will be passing in a large number of parameters which could exceed the limit imposed on GET requests by the receiving web server, you should switch to POST instead.

Here is a site which surveyed the GET behavior of most modern browsers, and it is worth a read.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • 1
    HTTP is line-based, so you can't really talk about packets. The only difference between GET and POST is that the POST data comes after the headers. – Blender May 20 '15 at 06:11
  • 3
    Using POST to effectively GET the result of a search is not RESTful. –  May 20 '15 at 07:16
  • 3
    For educational purposes, how do you propose to send a request for reading information if the parameters won't fit in a GET? – Tim Biegeleisen May 20 '15 at 07:19
  • 3
    @Time Use `POST /queries` to create a new 'query' instance. The response would be `201 Created` with a location header. Then `GET /queris/id-of-query-as-assigned-by-the-server` would be used to retrieve the result of the computation. That' would be RESTful since it deals with resources. Responding to a POST with the result *in the response body* is RPC, not REST. –  May 20 '15 at 10:03
  • 1
    uh, yeah, that would also require you to design the persistence of that query, no thanks – hyankov Sep 22 '20 at 15:11
8

Late to the party but for anyone searching for a solution, this might help.

I just came up with 2 different strategies to solve this problem. I'll create proof of concept API and test which one suites me better. Here are the solution I'm currently thinking:

1. X-HTTP-Method-Override:

Basically we would tunnel a GET request using POST/PUT method, with added X-HTTP-Method-Override request header, so that server routes the request to GET call. Simple to implement and does work in one trip.

2. Divide and Rule:

Divide requests into two separate requests. Send a POST/PUT request with all payload, to which server will create necessary response and store it in cache/db along with a key/id to access the data. Then server will respond with either "Location" header or the Key/id through which the stored response can be accessed.

Now send GET request with the key/location given by server on previous POST request. A bit complicated to implement and needs two requests, also requires a separate strategy to clean the cached responses.

Nripendra
  • 359
  • 6
  • 12
  • Good to know it has a jargony name. "Divide and rule". This is a better description than in my answer. Don't like option 1 though. – JSDBroughton Mar 07 '17 at 10:41
  • 2
    Another possibility is that the POST would just save the request data as a resource (BUT will not look for the results) and return the id (of that resource). Then the GET would pass that id. The implementation would 1) query/get the results based on the saved request data 2) erase the request data, 3) respond with the results – inor Jan 23 '18 at 13:51
  • 1
    2 scales pretty good. Google's reverse Image search works like "Divide and Rule". Uploading image happens on POST /upload and then 302 is sent with URL for the actual result. – rentedrainbow Jan 10 '20 at 02:19
4

If this is going to be a typical situation for your API then a RESTful approach could be to POST query data to a buffer endpoint which returns a URI from which you can GET your results.

Who knows maybe a cache of these will mitigate the need to send "huge" blobs of data about.

JSDBroughton
  • 3,966
  • 4
  • 32
  • 52
1

Well You Can Use Both To get Results From Server By Passing Some Data To server

In Case Of One Or Two Parameters like Id

Here Only One Parameter Is Used .But 3 to 4 params can Be used This Is How I Used In angularjs

Prefer : Get

Example : $http.get('/getEmployeeDataById?id=22');

In Case It Is Big Json Object

Prefer : Post 

Example : var dataObj = 
          {
                name : $scope.name,

                age : $scope.age,

                headoffice : $scope.headoffice

          };    

var res = $http.post('/getEmployeesList', dataObj);

And For Size Of Characters That Can Be Passed In Query String Here Is Already Answered

Community
  • 1
  • 1
vijay
  • 10,276
  • 11
  • 64
  • 79
  • 2
    Technically this is possible. But it is not REST. What is the resource such a POST would be made agains? It obviously is not a collection resource. Your answer smells like RPC over HTTP. –  May 20 '15 at 07:18
  • the question in much more leaning toward what should be used in either cases ..well example that i gave looks **SIMPLE** but not exactly what angularjs shows on documentations. – vijay May 20 '15 at 09:03
  • Will probably get some flak from the purists, but this is not a terrible rule. Sometimes it just makes more sense to pass a payload to get an object you want - personally, I'd prefer if the spec allowed payloads to be sent with GET requests, but using a POST "not following spec" sometimes makes sense. – Levi Fuller Mar 05 '20 at 17:47
-12

If you're getting data from the server, use GET. If you want to post something, use POST. Payload size is irrelevent. If you want to work with smaller payloads, you could implement pagination.

mchandleraz
  • 361
  • 5
  • 15
  • 2
    "*Payload size is irrelevant*" - in theory. – JensG May 20 '15 at 08:09
  • The payload as described us not irrelevant. Pagination of results always makes sense, not often feasible for queries. – JSDBroughton May 20 '15 at 08:17
  • 2
    all "the stuff" you want to pass in the GET request is encoded into a URL. since URL is limited to x chars, size is relevant. The question was what do you do when the size of a GET could potentailly exceed the url limitation – inor Jan 23 '18 at 16:32