4 ms·

IMO, the benefits of HATEOAS are very much overblown - many circumstances you have full control over the version of both client and server, and all it is doing

IMO, the benefits of HATEOAS are very much overblown - many circumstances you have full control over the version of both client and server, and all it is doing is adding an extra layer of indirection that allows extra complexity and ambiguity to sneak in. Instead of the client depending on a specific known API endpoint, it depends both on the endpoint you give it at runtime and the process that serves that endpoint to the client. And as a bonus, the client now "helpfully" obfuscates what endpoints it needs to render which pages - what you could figure out with straightforward grep for something like "api/v1/books" now needs a deeper understanding of the application. Like, the way in which the client accesses the "deposits" functionality is either fixed or can dynamically change. If it's fixed, the indirection serves no purpose - just have the client do the thing in the one way that you ever have the client do the thing. If it can dynamically change, the state space involved can and often will grow out of control in a hurry, and I strongly suggest pushing back on designs that require structural dynamism like this.

berkes 5y ago
You may not have encountered another use-case. This is not only about design-time versus run-time. But a large part about "where to have business-logic". Say simple use-case where you have web/android/ios clients, which show an invoice after the payment is processed (and not cancelled, pending, halted, flagged-for-terrorist-double-check, or whatever banks come up with tomorrow). You either have one service determining "there is an invoice" or "there is no invoice", or you have all your web/andoid/ios clients implement this logic and have to keep it in sync. Not only is this flakey, it introduces very tight coupling to fields and their values. I've seen abominations such as `status == "pending" || status == "PENDING" || status == "PendingValidation" && validation == false`, (edit) repeated in every client (and obviously slightly different). Moving this to a single point of truth comes with a lot of benefits. But when you don't ever have such business-logic, by all means, skip all the indirection and just render whatever comes back, based on a swagger doc you read for version x.y.
- ThrustVectoring 5y ago
  You don't need to go full HATEOAS to consolidate most business logic in server-side API. Like, this is just an example of an awkward API that exposes `status` and `validation` and makes clients do the business logic, rather than one that exposes `hasInvoice` and/or `invoiceId`. The HATEOAS bit is sending across a URI instead of a resource ID, which only helps when there's business logic for which endpoint to use for a specific resource ID that needs deduplication. And even that is only necessary when the client must make the request directly and can't proxy through a "figure out which endpoint to use and delegate it" endpoint. To be specific, HATEOAS would help when Visa and Mastercard need to use different endpoints for the invoice, and the payment networks require the client to directly query their endpoint rather than going through a server API you control.
  - berkes 5y ago
    I've worked with APIs that used IDs to communicate state. While that works, IDs are a poor abstraction to communicate possibilities. IDs are good for structuring relations and composition (hasMany, belongsTo etc) whereas links indicate actions. An ID says: "there is a thing somewhere". A link says "you can do somthing there". My example of "getting an invoice" is a bad one for this, because a GET is where IDs and links overlap. "There is an invoice somewhere" is almost the same as "there is an invoice there". It becomes more apparent when creating things. No ID can communicate that a client may add a payment. Or can delete a tag. Or can move an item. Links can do that. So, I find that links are better abstractions because they cover all these cases whereas IDs cover only a subset.
recursivedoubts 5y ago
> IMO, the benefits of HATEOAS are very much overblown Much overblown in the context of JSON APIs. In this article I am (in part) arguing that HATEOAS (and, therefore, REST) don't make much sense when working with JSON, but make a ton of sense when working with HTML, and, therefore, when building hypermedia-based systems.

berkes 5y ago

You may not have encountered another use-case. This is not only about design-time versus run-time. But a large part about "where to have business-logic". Say simple use-case where you have web/android/ios clients, which show an invoice after the payment is processed (and not cancelled, pending, halted, flagged-for-terrorist-double-check, or whatever banks come up with tomorrow). You either have one service determining "there is an invoice" or "there is no invoice", or you have all your web/andoid/ios clients implement this logic and have to keep it in sync. Not only is this flakey, it introduces very tight coupling to fields and their values. I've seen abominations such as `status == "pending" || status == "PENDING" || status == "PendingValidation" && validation == false`, (edit) repeated in every client (and obviously slightly different). Moving this to a single point of truth comes with a lot of benefits. But when you don't ever have such business-logic, by all means, skip all the indirection and just render whatever comes back, based on a swagger doc you read for version x.y.

ThrustVectoring 5y ago
You don't need to go full HATEOAS to consolidate most business logic in server-side API. Like, this is just an example of an awkward API that exposes `status` and `validation` and makes clients do the business logic, rather than one that exposes `hasInvoice` and/or `invoiceId`. The HATEOAS bit is sending across a URI instead of a resource ID, which only helps when there's business logic for which endpoint to use for a specific resource ID that needs deduplication. And even that is only necessary when the client must make the request directly and can't proxy through a "figure out which endpoint to use and delegate it" endpoint. To be specific, HATEOAS would help when Visa and Mastercard need to use different endpoints for the invoice, and the payment networks require the client to directly query their endpoint rather than going through a server API you control.
- berkes 5y ago
  I've worked with APIs that used IDs to communicate state. While that works, IDs are a poor abstraction to communicate possibilities. IDs are good for structuring relations and composition (hasMany, belongsTo etc) whereas links indicate actions. An ID says: "there is a thing somewhere". A link says "you can do somthing there". My example of "getting an invoice" is a bad one for this, because a GET is where IDs and links overlap. "There is an invoice somewhere" is almost the same as "there is an invoice there". It becomes more apparent when creating things. No ID can communicate that a client may add a payment. Or can delete a tag. Or can move an item. Links can do that. So, I find that links are better abstractions because they cover all these cases whereas IDs cover only a subset.

recursivedoubts 5y ago

> IMO, the benefits of HATEOAS are very much overblown Much overblown in the context of JSON APIs. In this article I am (in part) arguing that HATEOAS (and, therefore, REST) don't make much sense when working with JSON, but make a ton of sense when working with HTML, and, therefore, when building hypermedia-based systems.