3 ms·
The article assumes having HATOAS is somehow more important than having an API. Maybe it's not. SQL and JSON APIs share the same vision (dis)regarding HATOAS.
by weddpros 11y ago
The article assumes having HATOAS is somehow more important than having an API. Maybe it's not.
SQL and JSON APIs share the same vision (dis)regarding HATOAS. A foreign ID in SQL looks like a JSON field with an ID in it. HATEOAS links are more like storing SQL statements as a foreign key.
So if you think SQL did it right, so did JSON without HATEOAS.
If HATEOAS was such a nice feature, everybody would use it in JSON APIs. Its proponents always say the world would be better with it, but the world disagrees.
- icebraining 11y agoI'd say that HATEOAS links are like foreign key constraints. In a JSON document, you get an ID, but there's no semantic information about what it refers to, it's just a number. In SQL, on the other hand, the table has that metadata, and so it can tell you that the number refers to a specific record of table <X> - just like the link in HATEOAS encodes the specific document it's referring to.
- weddpros 11y agoSome databases don't even support explicit foreign key constraints, and SQL doesn't make their declaration mandatory. And that metadata is not in the resultset, you get an id instead. So SQL dbs will happily let you join with the wrong table. Also foreign key constraints don't play well with sharded SQL dbs. For these reasons, I don't see SQL as a good parallel to HATEOAS. Maybe an ORM would be closer to what HATEOAS brings... It's all about impedance mismatch I think... but HATEOAS is no more a definite solution than ORMs.