Hacker News Reader

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.

> 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.

The 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.

It helps to clarify what will happen. GET requests should never alter the data in the backend, wheras PUT, POST and DELETE would.

If it's an unauthenticated call you can use a browser, but if all the calls require a header like that, I don't see a reason to.