undefined | Better HN

0 pointsdragonwriter11y ago0 comments

> People right on HN spend their time arguing over what is restful and what isn't ,because vague "semantics".

The defined semantics of HTTP/1.1 methods (REST is a style, but HTTP/1.1 is a standard) are not vague.

> And to be frank, if you're not using HATEOAS , there is very little difference between a api with beautiful urls and a few headers and rpc.

If you aren't using HATEOAS, you aren't using REST. That doesn't necessarily mean that it is indistinguishable from RPC.

> The original spec is brilliant yet way to vague to be useful.

What original spec are you talking about?

> RPC isn't HTTP,

Neither is REST, though HTTP is itself an example of REST and a protocol which is fairly convenient for use in REST services.

> which is totally handy in the context of micro-services as one can implement RPC over any protocol. that's not the case for Rest...

> On the contrary, it is rather central to the point of the REST architectural style that you can implement it over any protocol (or, given hypertext formats which support identification of different protocols, over any combination of protocols simultaneously.)

From the creator of REST [0]:

A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.]

[0] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

0 comments

2 comments · 1 top-level

aikah11y ago· 1 in thread

> If you aren't using HATEOAS, you aren't using REST.

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.

lmorchard11y ago

Everyone writing a web page with links you can click on to navigate through a web site understands HATEOS.

It's just that, for some reason, when you shift to imagining a robot interacting with your site rather than a person, people get confused.

Though, really, I know that the reason is that they're trying to shoehorn an existing set of APIs into this cool REST thing they've heard about. In reality, you need to look at it from the other direction. Or, don't try wrestling with REST.

1 more reply

j / k navigate · click thread line to collapse