1

I want to make a database query from frontend (Angular) to backend. But I need to send lots of parameters for that.

As far as I understand, if we are not making any database changes, it is better to use GET as it uses cached entries. POST should be used used if we need to make changes on server/DB.

But if I want to send many parameters (some are serialized objects) and make no server side changes, will it be alright to use POST request in that case and embed all parameters in the POST body instead of sending a huge URL encoded GET request?

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
Aman Gupta
  • 3,627
  • 4
  • 40
  • 64

2 Answers2

1

To first clear this up: responses to POST requests can be cached, as long as the origin server returns the proper caching response headers. However, browsers and proxy servers generally don't apply caching to POST requests.

That being said, with the proper encoding you can store a lot of information in the ~ 2 KB of a query string, so GET should be the way to go.

If you're certain you'll go beyond the limits of a GET request and you'll need to go the POST way while remaining cacheable, you could introduce a kind of "nonce", for example using a hash of the search parameters:

  1. Client does a POST to /search, with the search parameters.
  2. Server stores the parameters somewhere, for example in a database.
  3. Server generates a nonce from the parameters, for example by hashing the search parameters, or the row ID.
  4. Server redirects the client to the result page for that nonce: /search/123abc.
  5. Client requests the /search/123abc search results page.
  6. Server performs the search based on the nonce, and returns a response which is cacheable.

This will introduce one additional HTTP roundtrip, but enable caching cross-browser and through proxy servers.

Community
  • 1
  • 1
CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • Good approach. It gave me a different idea also. Use btoa(https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/btoa) to encode the stringified object of parameters and send the encoded data as param in GET request. On server, decode the param and parse the param and get things done. How about this? – Aman Gupta May 06 '16 at 10:09
  • This will save us one round trip which is a caveat in your approach. – Aman Gupta May 06 '16 at 10:11
  • Yes of course the additional roundtrip is a drawback, but it enables what you want: large requests whose responses are cacheable. How to properly encode your search parameters is a different question altogether, and depends greatly on the nature of these parameters. Lots of strings and numbers don't encode that well into a smaller format, while lots of booleans do. – CodeCaster May 06 '16 at 10:18
0

I think you should use post in this situation which is more manageable and looks clean. For more benefit of post follow these links:

Sk. Tajbir
  • 290
  • 2
  • 9
  • _"More manageable and looks clean"_ aren't really properly defined properties you're looking for when building software, and [link-only answers aren't answers](http://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers). Please explain explicitly how POST is "more manageable" than GET. – CodeCaster May 06 '16 at 09:50
  • You can use both get and post in your situation and from your question it seems like you've good knowledge on get and post, but I just given my opinion depending on my experience. By manageable I meant anytime you can change your field name easily and don't have to make a big string for get request and by clean I meant that there will be no big ugly request string in your code. Also I probably given my answer on the comment section but I cannot do that right now. Let me know your thoughts. Thanks. – Sk. Tajbir May 06 '16 at 10:03