Do you hate HATEOAS?



  • Sounds like something I eventually will.


  • BINNED

    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?


  • BINNED

    @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.


  • BINNED

    @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.


  • BINNED

    @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 undefined 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. 😄

    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…


Log in to reply
 

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