Who Cares about GET vs. POST? NoREST

They don't care what the internal function names are but they do care about the language of the domain, and if the internal program is well written then those will be one and the same. The HTTP verb model is inadequate for domains of realistic complexity; imagine a developer looking for the method that flubbleizes the worzwort. Is this POST /worzworts/12345 ? PATCH /worzworts/12345 ? If you squint at it then flubbleizing is kind of like adding another bishwiggle, so maybe it's PUT /worzworts/12345/bishwiggles ? Most people tend to realize that these domain-specific operations don't have a HTTP representation and instead make them a POST with the specific operation in the URL. But then you end up with an api that looks like:

    #flubbleize a worzwort
    POST /worzworts/12345/flubbleize
    #mrefgle a worzwort
    POST /worzworts/12345/mrefgle
    #chezzle a worzwort
    POST /worzworts/12345/chezzle
    #delete a worzwort
    DELETE /worzworts/12345

> If you ignore HTTP verbs and status codes you're just making it harder for other developers to grok your system. It's less about adherence to some strict standard and more about helpful signaling. A GET fetches data, POST creates new records, PUT is idempotent, DELETE deletes. 4xx status codes indicate a request error, 5xx indicate a server error. That's all useful information for someone trying to integrate with your API, but you think that instead everyone should memorize your in-house conventions. Good luck getting buy-in on that.

The developer doesn't start by knowing that something is a PUT and trying to figure out what it's doing - they start by knowing what they want to do and trying to figure out the call. The world isn't consistent enough for them to be able to guess, and splitting the call into two parts - verb and path - makes it harder to remember once you've looked it up, not easier.

4xx vs 5xx is maybe valuable, but the very fact that you xx it suggests that the difference between 412 and 422 probably isn't important. In practice every REST API I've seen has felt the need to include a response body that a) explains the error and b) includes their own API-specific error code. In which case, why repeat yourself badly in the HTTP status code?

Then almost no REST api i've seen out there the is a REST api,which is my point exactly.

If you're writing a spec almost nobody understands and almost nobody truly implements yet everybody think they implement, then you failed at writing that spec. Because I can guarantee you out there a only few people understand HATEOAS.

And that's the heart of the problem. The reason is easy. While the idea of using a few verbs, etags and content negotiation is easy, HATEOAS is hard,period.It's hard the person who implements the api ( because someone has to code all the logic representing these states, the links, ...) ,it's hard for the client: the client has to be smart, urls aren't hard coded but need to be fetched from somewhere , and the body of a response needs to be parsed to know in which state the resource is, the actions, the relationships between resources, or sometimes the links are in the headers... You're not just sending data but also metadatas (just like RPC) that are only relevant in the REST logic, not in the actual application logic ... you're basically writing a web bot every time you're writing a rest client... All that for what? elegance basically.

As your link says, most devs are just using RPC with beautiful urls to begin with and stamp "RESTfull" on that. Don't you think there is a real issue here? I do.

There is no such thing as a RESTful URL. Characters in URLs don’t matter.

GET and POST have different semantics. Ignoring the benefits of caching is just dumb.

The semantics of status codes and verbs are defined pretty clearly. You might have to read an actual spec.

A paragraph starting with “A core difference between REST and RESTful …” physically hurts.

I can’t believe I just wasted time actually commenting on this.