Comment by JimDabell
7 years ago
> I'm not saying it needs a universal client, just that it's the only real reason I can think of for including all of that.
I already gave several examples of reasons why you would do it this way in my earlier comment.
Why have we leapt from the garage remote example to a FitBit that tracks vehicle mileage? I don't see why you keep leaping to "it must handle everything everywhere". Stop thinking about handling everything under the sun – we're talking about a garage remote.
> If you were going to craft a client UI based entirely off the server responses, you are going to recreate the Gopher experience, and nobody wants that.
REST is a distillation of the principles that make the web work. Can you see the parallels with how HTML forms work? Browsers don't need to know that contact forms need to be POSTed to /contact, the server sends the client a document describing the action to take.
Okay - so to put my question in terms of the garage remote example, say the API offered is_open, open_door, and close_door functions.
A "dumb" client that is configured by the server is going to include all three. Image a developer that only wants the UI to be a toggle that mimics an actual hardware button? That would require some a priori knowledge of what the API supports. The list of actions is perhaps useful for the developer before they write their code. But then version 2 of the API may remove the close function and expand open to accept a value between 0 and 1. The client is going to need to be updated and the action list will again be useful for an afternoon.
> Can you see the parallels with how HTML forms work?
Okay - now that's a fantastic question that has me reconsidering everything I said. I think what's special about HTML forms is that the browser is the universal client. I have to think about that more though.
I appreciate you trying to help me see the light here. This is something that has bothered me since I first started reading about REST.
I've been diligent about HATEOAS links for years, but recently stopped bothering. They've never actually been used in practice. While the concept of a universal HATEOAS client has been around forever, there's no real world use case for them. The whole idea is a solution looking for a problem.
I still am having a hard time with the concept.
Going back to the garage door example. Say I'm building a wifi opener. It's going to have one button that acts like a toggle, just like regular garage door openers. Press the button and the door opens. Press it again and the door closes.
In the firmware, it will contact the opener server and it can get a list of actions and endpoints. But if version 2 of the server changes the action name from open to door_open, then my button is broken even though I've diligently followed the HATEOAS model.
1 reply →