31 ms·
Caching for one. I just don't see a reason for moving as much as possible to POST since this seems to go against what the different methods (GET, HEAD, POST, PU
by Revell 11y ago
Caching for one. I just don't see a reason for moving as much as possible to POST since this seems to go against what the different methods (GET, HEAD, POST, PUT, DELETE, etc) were meant for.
- dragonwriter 11y ago> I just don't see a reason for moving as much as possible to POST since this seems to go against what the different methods (GET, HEAD, POST, PUT, DELETE, etc) were meant for. Arguably, HTTP-based RPC with consistent use of POST is a lot more straightforward of a model than the kinda-sorta-REST-without-HATEOAS that a lot of APIs use, and arguably for APIs whose scope is a particular server and not the kind of generality that the web as a whole itself (the archetypical REST service) provides, POST-based HTTP-RPC is a more natural choice than REST.
- smarx 11y agoThe new API does support GET for requests that are cacheable (e.g. fetching a file or thumbnail). The RPC-style endpoints all use POST and are not cacheable.