0

I read it in this post that

An operation behind a GET endpoint does not change the target state of the server therefore the response of a GET endpoint can be cached resulting in further requests to the same endpoint being returned faster from the cache

An endpoint behind PUT, POST, PATCH and DELETE changes the target state of the server therefore a successful response out of any of these endpoints can be used to bust the previously cached responses.

So using GET wherever we can, can impact performance(faster responses).

But only using POST instead of other verbs PUT, POST, PATCH and DELETE, can this impact performance(faster responses) in any way or it is just for developers to understand what the API's does?

Thanks.

Sudhanshu Gaur
  • 7,486
  • 9
  • 47
  • 94
  • Taking a look at https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html could shed some light on this issue. I especially recommend the section about "Safe and Idempotent Methods". –  Jul 13 '18 at 13:40
  • 1
    @LutzHorn RFC 2616 got obsolete by RFC 7230-7235 (i.e. https://tools.ietf.org/html/rfc7231#section-4) – Roman Vottner Jul 13 '18 at 14:47
  • HTTP is a protocol for managing resources on remote machines Any business rules you infer from interacting with HTTP servers are just side effects of the resource management actually. Each of the verbs defines certain semantics that enable interoperability as long as each peer sticks to the same semantics. The safe property is useful for i.e. crawler which assume that invoking a URI is safe for them (i.e. does not trigger a order for something or deletes user records or what not). – Roman Vottner Jul 13 '18 at 14:59
  • @RomanVottner So is there any performance impact? As we can see in terms of using GET. – Sudhanshu Gaur Jul 13 '18 at 15:09
  • It depends on what you understand as performance impact. `GET` resposes are cachable by default which allows intermediary (or the serivce itself) to simply return a previously calculated state, so the servcie actually might never take notice of the request to start with - best performance improvment there is. POST responses are only cacheable if they contain [explicit refreshness information](https://tools.ietf.org/html/rfc7234#section-4.2.1). If the actual performed action on the server are more performant than other methods depend on the implementation of the business logic actually. – Roman Vottner Jul 13 '18 at 15:18
  • Also see: https://stackoverflow.com/questions/626057/is-it-possible-to-cache-post-methods-in-http – Roman Vottner Jul 13 '18 at 15:22
  • 1
    My advice (decades of experience). Don't get tricky regardless of the performance increase (most likely minor). You WILL regret it. I have seen someone use ALL gets (even for updates) in an attempt to "speed it up". Did not work out well. – John White Jul 13 '18 at 16:47
  • @JohnWhite Thanks for your advice but as it is nearly 2.5 times faster than normal HTTP protocol, I think it is a much-needed thing. – Sudhanshu Gaur Jul 13 '18 at 16:53

0 Answers0