24 ms·

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` a

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.