6 ms·

Web browsers aren't HATEOS clients, the web sites/applications they make accessible are. I work with a team on a complex web service and agree with all of Stev

Web browsers aren't HATEOS clients, the web sites/applications they make accessible are. I work with a team on a complex web service and agree with all of Steve K's points. A REST-like approach using appropriate HTTP verbs and a good resource design are (given the right use-case) a big win. The problem for me with HATEOS evangelists is that they seem to think it solves more problems than it actually does. Sure, we now have a layer of abstraction between logical and http link but for anything other than trivial changes you always have to have human readable documentation. HATEOS works brilliantly for the web because there is a human at other other end who understands what "new comment" is and how it's different from "new private message". My customers' API clients don't have this semantic understanding. Now I know that it helps dev's if they can navigate around my API but it's no substitute for well written documentation; HATEOS API's are something to strive for but not self-describing as some claim.

parasubvert 14y ago
I agree that most clients don't have that sort of semantic understanding. that's because we are still at a stage where most of our APIs are just custom media types and a moderate improvement over yesteryear's WSDL. The improvement is the use of URIs and HTTP GET to mash data. But the point of HATEOAS is that it doesn't have to be this way. The number of generic link relations are increasing, as are the numbers of useful generic media types. We are getting smarter, as an industry, with how to describe semantics in a machine readable way. It's a slow process because building generic designs is really hard. Today's HATEOAS advocates are trying to progress the state of the art, I can completely understand why a individual API author might ignore that constraint though. Perhaps it's futile but I'm not certain our future 10+ years out is eternally building hard coded mashups.
habitue 14y ago
> there is a human at other other end who understands what "new comment" is and how it's different from "new private message" That's the great thing about media types and custom link relations, you can express the relationships and the formats in a way that a machine can understand, and add new functionality while needing less hardcoding. The thing this doesn't solve (in principle) is exposing new media types and relationships, that definitely requires updating on the client's end. But, it's a much better situation than "this url has a document with this format, I'll wget that url at the start of my program, parse this stuff out of it etc.."

parasubvert 14y ago

I agree that most clients don't have that sort of semantic understanding. that's because we are still at a stage where most of our APIs are just custom media types and a moderate improvement over yesteryear's WSDL. The improvement is the use of URIs and HTTP GET to mash data. But the point of HATEOAS is that it doesn't have to be this way. The number of generic link relations are increasing, as are the numbers of useful generic media types. We are getting smarter, as an industry, with how to describe semantics in a machine readable way. It's a slow process because building generic designs is really hard. Today's HATEOAS advocates are trying to progress the state of the art, I can completely understand why a individual API author might ignore that constraint though. Perhaps it's futile but I'm not certain our future 10+ years out is eternally building hard coded mashups.

habitue 14y ago

> there is a human at other other end who understands what "new comment" is and how it's different from "new private message" That's the great thing about media types and custom link relations, you can express the relationships and the formats in a way that a machine can understand, and add new functionality while needing less hardcoding. The thing this doesn't solve (in principle) is exposing new media types and relationships, that definitely requires updating on the client's end. But, it's a much better situation than "this url has a document with this format, I'll wget that url at the start of my program, parse this stuff out of it etc.."