Do you hate HATEOAS?



  • I wish to ask for your opinions about HATEOAS. It seems to have its pros and cons, as usual. I've seen one project where it's the perfect thing not to use. What do you think about it?


  • :belt_onion:

    TIL hypermedia is a thing :wtf:

    I honestly never heard that term before. Given how stupid it sounds, I hope I never will again.



  • As with all things RESTful, the terminology is gibberish. In essence, it's a notion of not using predefined REST interfaces, but building them dynamically for each resource. You have some single entry endpoint which leads you to resource A, which tells you what actions can be taken on it with possible link to resource B etc. I'm not going to say what I think about it to not infect any potential discussion, but I hope some other people came across it and have some opinions.


  • :belt_onion:

    Yeah, I kinda got that bit, though I half stopped reading after getting hit by the "hypermedia" thing.

    Sounds very... Enterprise-y. I never had to wrangle with it, but at the first glance it looks like looking for trouble to me.



  • :wtf: is this?!


  • Discourse touched me in a no-no place

    There's a metric buttload of crap written about it, but the basic idea is actually reasonable. The principle is that you should make the responses that you serve back to REST requests (especially to GETs) be self-describing; if there are sub-resources, there should be links to those sub-resources so that nothing needs to guess the URLs or what they mean (at some level). Like that, you can just use a browser and follow links to at least get a reasonable read-only view of what's going on. (You can also use content negotiation to do better, but you don't have to.)

    Which isn't to stop you from also describing how to use the REST application in other ways too. (My REST apps both follow HATEOAS and publish a WADL description; which is the most convenient form for a client depends on the client.)



  • If it was a good idea, it wouldn't have such a shitty name.



  • It doesn't bode well when something has "HATE" in the name, does it?



  • It's nice, but nothing you'll ever see correctly implemented. I can't count the amount of crappy APIs (crAPIs?) I have to struggle with every day. For example, right now I'm working with an API which has only one endpoint and all requests are like:

    POST: /getPage
    post-data: {"page":"dashboard"}
    

    And another one which contains some URLs that aren't really pointing to anything and usually end up in a 400.



  • I think the approach should be directly tied to use cases. The one service I mentioned is such crap that it takes more time to actually work around its crappyness, than to get things done.



  • I'm picturing you with a big chart up on the wall, showing all of the states you've explored to, annotated with special cases, danger zones, and shortest routes between common states and important resources.

    No idea how far off that is; I just read the wiki article and let my imagination run wild.



  • Ok, let me tell you my thoughts and let's see what you think about it.
    IMHO, if you know upfront what you want to do and the subject you want to work on, HATEOAS is absolutely not the way to go. You need a simple IDL of some sorts, which you can use to call the service directly and live happily ever after.
    But if you have no knowledge of the resources to work on, or the actions available on them, HATEOAS seems to be a good way to expose the system interface.
    That in turn leads to a problem - if you take the HATEOAS approach, you have no need of any backwards compatibility, but if you use a WADL approach, you need to maintain previous versions of the interface (for some deprecation time at least). This in turn implies the whole HATEOAS approach has no sense, since you already need to maintain a versioned interface. And this implies I need a drink.



  • Having had to deal with Oracle's OAS I find the name endlessly amusing.



  • @NeighborhoodButcher said:

    I wish to ask for your opinions about HATEOAS.

    Sounds like a racist breakfast cereal.



  • I seem to be a magnet for WTF technologies.


  • Discourse touched me in a no-no place

    @NeighborhoodButcher said:

    if you use a WADL approach, you need to maintain previous versions of the interface (for some deprecation time at least).

    Only if you're making breaking changes (i.e., changes that don't extend the API, such as removing a resource) instead of extensive changes. It's just like when you're making changes to an API to a library; adding another method or class doesn't really have to cause many problems for anyone, but deleting a public class is going to be trouble.

    It all ultimately comes down to what happens with the messages on the wire. If you continue to accept the messages you used to accept and to generate compatible responses, you don't need to worry about evolving the interface description itself.



  • @dkf said:

    adding another method or class doesn't really have to cause many problems for anyone

    Pedantic comment: except for ABI and all that stuff.

    @dkf said:

    If you continue to accept the messages you used to accept and to generate compatible responses, you don't need to worry about evolving the interface description itself.

    Yeah, that's what I meant be keeping it backwards compatible. That's where HATEOAS shines, but if you want to do a simple "do X on Y", you really don't want to go through the complete tree of resources just to get a URL. Let me give the example of the horrible service I originally mentioned. Someone computed it's necessary to do over 9200 requests just to GET one specific resource. That really swings the pendulum in favor of WADL (or a hybrid).


  • Discourse touched me in a no-no place

    @NeighborhoodButcher said:

    Pedantic comment: except for ABI and all that stuff.

    Pedant pendant: evolving the ABI is possible too, just tricky. (Also highly irrelevant to this topic.)

    @NeighborhoodButcher said:

    Someone computed it's necessary to do over 9200 requests just to GET one specific resource.

    :wtf:



  • @dkf said:

    @NeighborhoodButcher said:
    Someone computed it's necessary to do over 9200 requests just to GET one specific resource.

    :wtf:

    Have I said I'm a WTF magnet?


  • Discourse touched me in a no-no place

    @NeighborhoodButcher said:

    Have I said I'm a WTF magnet?

    In that case… have you tried using WS-SecureConversation yet? :smiling_imp:



  • Sounds like something I eventually will.


  • :belt_onion:

    You know, that name actually made me interested for a bit there. WS? WebSockets? Is there something using WebSockets for a more serious purpose than a webchat?

    Oh... so... no WebSockets?



  • You really thought an IBM solution will use a standard?


  • :belt_onion:

    @NeighborhoodButcher said:

    You really thought an IBM solution will use a standard?

    I'm a hopeless romanticoptimist.



  • Do you hate HATEOAS?

    Yes, because no matter how many times I read the official explanation, I still have no idea what it means.



  • WS- is the prefix W3C members uses for Web Services extensions, such as WS-Addressing and WS-Federation.


  • Discourse touched me in a no-no place

    @NeighborhoodButcher said:

    You really thought an IBM solution will use a standard?

    Of course. IBM will be very busy writing the standard to fit their solution after all…



  • @Bort said:

    Yes, because no matter how many times I read the official explanation, I still have no idea what it means.

    As Einstein once said:

    If you can't explain it simply, you don't understand it well enough.

    I guess the authors of HATEOAS don't understand it either.


  • Discourse touched me in a no-no place

    @Onyx said:

    WS? WebSockets?

    If only! It's the prefix used by specs in the OASIS Web Services stack (plus a few others) and I really don't like them very much at all. I forget which one it is that effectively requires the downloading and building of a whole new client stack on each connect (or something like that) but even with a dynamic language that's really nasty.

    They're a sort of weird brain pollution.


  • :belt_onion:

    @dkf said:

    Of course. IBM will be very busy writing the standard to fit their solution after all…

    <insert obvious XKCD here>



  • @dkf said:

    The principle is that you should make the responses that you serve back to REST requests (especially to GETs) be self-describing

    Isn't that what you do when you serve HTML to be rendered by standard browser?

    In most other cases it sounds like second system syndrome. The logic still needs to be written somewhere, so it's not like it would save any work.


  • Discourse touched me in a no-no place

    @Bulb said:

    Isn't that what you do when you serve HTML to be rendered by standard browser?

    That's one of the ways to do it.
    @Bulb said:
    In most other cases it sounds like second system syndrome. The logic still needs to be written somewhere, so it's not like it would save any work.

    One of the better HATEOAS principles is that the client doesn't invent any URLs (other than through normal mechanisms like using a <form>) and leaves that entirely to the server. That should result in it being easier to evolve what URLs are available, what content types are supported, what operations are supported, that sort of thing.

    It's widely misunderstood, and even more widely Done Wrong™…



  • The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. By contrast, in a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).

    Unless I've missed something, a REST client is a piece of software, not a person, and unless you're an AI researcher your software can't dynamically figure out what you want it to do with the server responses, you have to program in the logic.

    All future actions the client may take are discovered within resource representations returned from the server. The media types used for these representations, and the link relations they may contain, are standardized. The client transitions through application states by selecting from the links within a representation or by manipulating the representation in other ways afforded by its media type. In this way, RESTful interaction is driven by hypermedia, rather than out-of-band information

    [...]

    HTTP/1.1 200 OK
    Content-Type: application/xml
    Content-Length: ...
    
    <?xml version="1.0"?>
    <account>
       <account_number>12345</account_number>
       <balance currency="usd">100.00</balance>
       <link rel="deposit" href="/account/12345/deposit" />
       <link rel="withdraw" href="/account/12345/withdraw" /> 
       <link rel="transfer" href="/account/12345/transfer" />
       <link rel="close" href="/account/12345/close" />
     </account>
    

    I guess if you were making some interactive tool that presented options to the user, this could be useful. Otherwise you'll need to know about the deposit, withdraw and transfer actions before writing the program anyway if you want to do anything with them.

    I remember when some people claimed things like "XML allows different programs to share data without any prior knowledge of each other!" Yes, congratulations, so does plain text, but you still need to know what to do with the data.


  • Discourse touched me in a no-no place

    @anonymous234 said:

    I guess if you were making some interactive tool that presented options to the user, this could be useful. Otherwise you'll need to know about the deposit, withdraw and transfer actions before writing the program anyway if you want to do anything with them.

    I remember when some people claimed things like "XML allows different programs to share data without any prior knowledge of each other!" Yes, congratulations, so does plain text, but you still need to know what to do with the data.

    You could use the Semantic Web to describe everything so that clients can know directly what each does…

    I'll get my hat.


  • Grade A Premium Asshole

    @blakeyrat said:

    If it was a good idea, it wouldn't have such a shitty name.

    But what about: Twitter, Imgur, Bit.ly, Instagram...oh wait, nevermind.


  • :belt_onion:

    @Polygeekery said:

    Instagram

    I have to contest you here, sir! That's the sanest name of the bunch and the most useless one of the bunch at the same time. IMHO, at least.


  • Grade A Premium Asshole

    @Onyx said:

    That's the sanest name of the bunch and the most useless one of the bunch at the same time. IMHO, at least.

    Sanest, perhaps. But, if you take a person who has never heard of it before and gave them the brand name and asked them :wtf: it does...there is no way they will have any idea. Which I think was your point when you said:

    @Onyx said:

    most useless one of the bunch at the same time

    I just hate all of these idiotic product names. Spotify? Is it a laundry product for removing stains?



  • @dkf said:

    One of the better HATEOAS principles is that the client doesn't invent any URLs (other than through normal mechanisms like using a <form>) and leaves that entirely to the server. That should result in it being easier to evolve what URLs are available, what content types are supported, what operations are supported, that sort of thing.

    Well, not inventing URLs is not enough. Each function must come with complete description of the user interface that can be presented. So it either must be some UI description language (HTML/XUL/XAML/whatever) or there must be generic prescription how to turn it into such. And it only makes sense if presenting such UI to a human user makes sense in the first place which for many web services is not the case.



  • @NeighborhoodButcher said:

    What do you think about it?

    @Wikipedia said:

    A REST client enters a REST application through a simple fixed URL. All future actions the client may take are discovered within resource representations returned from the server.

    This sounds like a terrible idea to me. This put the onus of figuring out the details of the interface on each developer, rather than publishing a machine-readable API specification.

    For people who just write JavaScript in Vim all day, this seems like a good idea. To anyone that uses advanced tools (ETL Tools, Development Tools, etc...), this is a step back 15 years. I know there is a lot of XML hate out there, and people seem to dislike RPC-style APIs nowadays, but SOAP was great for tooling. WADL, JSON Schema, and several others are available, but much of the current generation of developers seems to think that these are useless. They seem to be OK with trading strong contract validation for human readability.


  • Discourse touched me in a no-no place

    @Jaime said:

    WADL, JSON Schema, and several others are available, but much of the current generation of developers seems to think that these are useless.

    FWIW, WADL makes for quite a nice way to actually consume a REST service in a GUI client once you've got the parser set up. (We've been doing some stuff that way with it.) The state of most tooling for consuming it isn't too great though; it's mostly pretty annoying.

    WADL has great tooling by comparison with JSON Schema. If you're insistent on having good tooling, stick with SOAP. SOAP has been around long enough that everyone and their uncle's lame dog has a reasonable implementation. Except maybe JS. :smile:

    And none of the above handle the real challenge, which is describing what the supported patterns of use are. A bit like too many other types of APIs I've seen…



  • @dkf said:

    If you're insistent on having good tooling, stick with SOAP

    I do. I also take crap from 90% of the people I meet for being a stick in the mud for not changing everything I touch to REST. I can live with the extra data on the wire.


  • Discourse touched me in a no-no place

    @Jaime said:

    I also take crap from 90% of the people I meet for being a stick in the mud for not changing everything I touch to REST.

    My services just support both. It means I have to have a clean idea of what the abstract operations are (since I use them to back both interface styles) but I think that's a really good plan anyway. It also makes it much easier to document: I talk about the abstract interface, and then just describe how it's mapped into REST and SOAP.



  • @dkf said:

    SOAP has been around long enough that everyone and their uncle's lame dog has a reasonable implementation. Except maybe JS.

    ... and Python 2.7.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    ... and Python 2.7.

    Really? That surprises me. With the number of Python programmers out there, I'd have thought that someone would have jumped in that particular sewer.



  • Yeah me too, actually. There are a billion out-of-date, no-longer-working, might-do-what-you-need-if-you-fix-it-yourself-and-are-lucky ones.

    Of course this is a language whose philosophy towards standard libraries seems to be "light and get away", so.



  • @anonymous234 said:

    I remember when some people claimed things like "XML allows different programs to share data without any prior knowledge of each other!" Yes, congratulations, so does plain text, but you still need to know what to do with the data.

    You're simply not using enough XML.



  • @Polygeekery said:

    Spotify? Is it a laundry product for removing stains?

    It sounds like it would be for doing the opposite of that... :/



  • @tar said:

    @anonymous234 said:
    I remember when some people claimed things like "XMLViolence allows different programs to share data without any prior knowledge of each other!" Yes, congratulations, so does plain text, but you still need to know what to do with the data.

    You're simply not using enough XMLViolence.

    Violence is a markup language that defines a set of rules for encoding documents in a format which is both human-readable and machine-readable. It is defined by the W3C's Violence 1.0 Specification[2] and by several other related specifications,[3] all of which are free open standards.[4]

    The design goals of Violence emphasize simplicity, generality and usability across the Internet.[5] It is a textual data format with strong support via Unicode for different human languages. Although the design of Violence focuses on documents, it is widely used for the representation of arbitrary data structures[6] such as those used in web services.

    Several schema systems exist to aid in the definition of Violence-based languages, while many application programming interfaces (APIs) have been developed to aid the processing of Violence data.



  • @ben_lubar said:

    Violence is a markup language

    But does it have SLAP errors and BITCH warnings?


  • :belt_onion:

    I like Violence. I use Crowbar Deluxe as my preferred editor.

    It's a bit pricey, but the licence is implicitly transferable, so if you manage to steal one from your neighbor you can get it for free! Just make sure he doesn't have an extra one laying around first.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.