tag:blogger.com,1999:blog-7395172357368553438.post470398999389859714..comments2022-04-12T01:40:46.270+02:00Comments on SOA Bits and Ramblings: Selling the benefits of hypermedia in APIsElfiskhttp://www.blogger.com/profile/01091018516358987653noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-7395172357368553438.post-3068881935905077082014-06-03T08:39:08.699+02:002014-06-03T08:39:08.699+02:00> I'd go as far as saying that for a machi...> I'd go as far as saying that for a machine client to use such a relational schema we'd need a pretty complex framework on the client.<br /><br />I somewhat agree with this - not that it need to be complex, but we need some kind of framework on the client. Thats why we need some standards for hypermedia and libraries for consuming those (as opposed to invent our own data formats). At this time of writing we have HAL, Mason, Sirene, Hydra, Collection JSON and a few more, each of them with varying support.<br /><br />But formats like HAL and Mason are pretty simple to use if you are already familiar with JSON. Links can be consumed as easy as Response._links["link-rel-name"].href - and thats it. I would argue that it is just as simple as creating links from templates.Elfiskhttps://www.blogger.com/profile/01091018516358987653noreply@blogger.comtag:blogger.com,1999:blog-7395172357368553438.post-29017673030489308182014-06-02T10:05:47.255+02:002014-06-02T10:05:47.255+02:00Thank you for the great article. I am currently ev...Thank you for the great article. I am currently evaluating HATEOAS for our API.<br /><br />The one question that keeps coming up though is that in theory HATEOAS sounds like a good idea, i.e. it decouples clients and servers, but in practice it sounds like implementing such a client would not be easy.<br /><br />For humans it sure makes it easier. Humans understand the business domain and will be able to understand the meaning of links in that context.<br /><br />However, machine clients need to follow either a schema defined by the API builders or use the links you mentioned from the IANA registry. Either way, the client code needs to be written in such a way that it will use some kind of logic to "understand" the link relations. I'd go as far as saying that for a machine client to use such a relational schema we'd need a pretty complex framework on the client.<br /><br />On the other hand constructing URLs on the client from documentation, i.e. tightly coupling the client to URLs instead of the schema, makes the coding of the client much easier. I do understand that if we do this we lose all the other benefits you mentioned, however selling HATEOAS to my client developers is much harder than selling URL construction.Louis Krugerhttps://www.blogger.com/profile/04623995038670852895noreply@blogger.comtag:blogger.com,1999:blog-7395172357368553438.post-61438311158738737242014-01-10T11:58:29.209+01:002014-01-10T11:58:29.209+01:00No, the examples are right. Relationships can eith...No, the examples are right. Relationships can either be registered short names from the IANA registry (see http://www.iana.org/assignments/link-relations/link-relations.xhtml) or unregistered complete URLs (which is used as a namespace mechanism). In the examples here I use URLs.<br /><br />Furthermore I want to make it explicit that I don't care about the actual API URLs in the links. So I use "{link-to-sales-orders}" to hide the actual link URL (which should anyway be irrelevant to the client - it is only the link relations that matter).<br /><br />Does that clarify it?Elfiskhttps://www.blogger.com/profile/01091018516358987653noreply@blogger.comtag:blogger.com,1999:blog-7395172357368553438.post-51894236606516019432014-01-10T11:50:39.979+01:002014-01-10T11:50:39.979+01:00I may be misreading, but the JSON examples appear ...I may be misreading, but the JSON examples appear to have the rel and href values swapped, i.e. href should contain the URI/URL and rel the "relation". Other than that, a nice post!Anonymousnoreply@blogger.com