3 ms·

Lots of excellent points in the article, but the problem I have with it (and HATEOAS in general) is that, like NakedObjects before it, it expects the model of t

by kitd 5y ago

Lots of excellent points in the article, but the problem I have with it (and HATEOAS in general) is that, like NakedObjects before it, it expects the model of the resources and what you do with them to mirror precisely the model the user understands and wants to do. Ie, it takes no account of UX and design principles. As a result, you end up with rather CRUDdy noun-oriented systems that don't really flow, with resources randomly thrown around by developers to try and make it make logical sense. A kind of accidental hypermedia complexity. I love the abstract concept of HATEOAS, but it needs some overarching architectural abstractions to help designers and developers implement just the resources and links needed. A great research opportunity there IMHO.

berkes 5y ago
Quite often, using nouns actually improves your architecture (and your Ubiquitous Language[0]). This design constraint is often one that pushes you in the right direction, but you have to allow it to push you. E.g. the classic "I want to archive this ticket". Three common approaches: POST/PUT /coupons/1337/archive PATCH /coupons/1337 { archived: true } POST/PUT /coupons/1337/archivals Designer now gives up. The second option is technically often the easiest (esp with CRUD frameworks like Laravel or Rails) but design wise by far the worst. The first is RPC-style and the last is suffering from what parent describes > As a result, you end up with rather CRUDdy noun-oriented systems that don't really flow What we see, however, is that our UL is lacking. What is it that we really do. What do we end up with?[1] We might "copy it to the archives" or "relocate it to the archives" etc, depending on your business case and domain details. We request a "relocation", which, when resolved, results in an "archived ticket". POST /archives/tickets/ { ...the entire ticket } or POST /tickets/1337/relocations It now adheres to REST, better describes the domain language, is consistent and flows quite alright. EDIT: the latter, for example, communicates that this may take a while (async), results in the ticket being moved elsewhere and the original one probably redirecting to the new. The former communicates clearly that we are making a copy or snapshot of the ticket in the archives. But there will always be cases where the verb makes more sense or adheres much better to the UL and domain. In such cases, one can still be resource-full and REST-full without introducing awkward nouns. E.g. in an CQRS setup, we interface with Commands. We can then request commands: `POST /commands/archive_ticket_command/` for example. --- [0] https://www.martinfowler.com/bliki/UbiquitousLanguage.html https://www.martinfowler.com/bliki/UbiquitousLanguage.html [1] Sidenote: I try to avoid words that are both a nound and verb. Like "archive". To archive vs In the archive: this causes ambiguity.*
recursivedoubts 5y ago
Yes, I agree entirely. The crux of the issue is that HTML has stalled as a hypermedia for a few decades now, but I am trying to fix that with htmx: https://htmx.org https://htmx.org htmx is the result of my research :)

by kitd 5y ago

berkes 5y ago

Quite often, using nouns actually improves your architecture (and your Ubiquitous Language[0]). This design constraint is often one that pushes you in the right direction, but you have to allow it to push you. E.g. the classic "I want to archive this ticket". Three common approaches: POST/PUT /coupons/1337/archive PATCH /coupons/1337 { archived: true } POST/PUT /coupons/1337/archivals Designer now gives up. The second option is technically often the easiest (esp with CRUD frameworks like Laravel or Rails) but design wise by far the worst. The first is RPC-style and the last is suffering from what parent describes > As a result, you end up with rather CRUDdy noun-oriented systems that don't really flow What we see, however, is that our UL is lacking. What is it that we really do. What do we end up with?[1] We might "copy it to the archives" or "relocate it to the archives" etc, depending on your business case and domain details. We request a "relocation", which, when resolved, results in an "archived ticket". POST /archives/tickets/ { ...the entire ticket } or POST /tickets/1337/relocations It now adheres to REST, better describes the domain language, is consistent and flows quite alright. EDIT: the latter, for example, communicates that this may take a while (async), results in the ticket being moved elsewhere and the original one probably redirecting to the new. The former communicates clearly that we are making a copy or snapshot of the ticket in the archives. But there will always be cases where the verb makes more sense or adheres much better to the UL and domain. In such cases, one can still be resource-full and REST-full without introducing awkward nouns. E.g. in an CQRS setup, we interface with Commands. We can then request commands: `POST /commands/archive_ticket_command/` for example. --- [0] https://www.martinfowler.com/bliki/UbiquitousLanguage.html https://www.martinfowler.com/bliki/UbiquitousLanguage.html [1] Sidenote: I try to avoid words that are both a nound and verb. Like "archive". To archive vs In the archive: this causes ambiguity.*

recursivedoubts 5y ago

Yes, I agree entirely. The crux of the issue is that HTML has stalled as a hypermedia for a few decades now, but I am trying to fix that with htmx: https://htmx.org https://htmx.org htmx is the result of my research :)