[justinhj]

Following the rules of REST is very important if you are presenting a public API to the world. If it's your own server you can do whatever you want. For example I used to work on servers for games and often there would be a single endpoint for processing one or more commands, and this would be technically a GET request regardless of what those commands did. Furthermore it's common to send application level error details with a 200 status code; i.e the http level transaction succeeded but the application layer produced an error. Much heated discussion emerges around these design choices :D

[jedberg]

> If it's your own server you can do whatever you want.

This is not at all true. For example, say I'm a user in a dorm that uses a proxy that I have no control over. If you make your GET request modify things, that proxy may cache the request, or worse, may repeat the request later to maintain its cache.

My point is, you don't know what is between your server and their client, and even well behaved infrastructure will sometimes make or modify GET requests on your behalf, but won't do that with POSTs.

[justinhj]

There are ways to make sure that your GET requests are not cached. For example in the case we're talking about here the server sets that URI to have "Cache-Control: private; max-age=0". Now sure, a proxy could simply ignore HTTP protocol and cache it anyway, but that would break a lot of things and AFAIK is not seen often in the wild. Certainly in the case of the applications I worked on we did not have customers that reported connection difficulties over HTTP.

[jonny_eh]

It's also an issue when you don't even fully control the client, which in this case is the web browser. A game at least behaves exactly as you program it. Browsers are not necessarily consistent, especially when you throw in extensions.

[jedberg]

Yes excellent point. Some browsers/plugins will prefetch every GET on the page to speed up browsing.

[Rebelgecko]

Some browsers also show a "here's your top 10 most visited webpages" shortcut when you make a new tab, which does a GET. I ran into that one when I was being lazy about building/testing an API.

[justinhj]

In the Hacker News case there isn't a GET request on the page, it's triggered by the javascript so this would not happen

[skohan]

As you say it will work just fine as long as your client and server agree, but free-wheeling it with the HTTP spec can come with operational drawbacks.

I've worked with a lot of different internal webservices as a freelancer, and if they're reasonably RESTful and built according to spec, it's easy to just get started with the codebase. Ones like you're describing mean a lot more conversations and reading through code.

Of course it depends on the nature of your team and how often you on-board, but to me the HTTP spec is one of those things like following coding style conventions: sure you don't need to do it, but at the end of the day it's not that much more work once you're in the habit, and it makes it that much easier to work with other people.

[justinhj]

I absolutely agree with your points, and that's good advice as long as your application works by modifying resources of a single type with each request. In my specific case we wanted to reduce round trips to the server by using compound commands that may do multiple things on the backend, affecting multiple entity types that would have to be, in rest, a resource. Also in our case my team was responsible for the client and the server, and the commands/responses are clearly documented for everyone to see.