4 ms·

We need a name for it then. Like NotReallyRESTButTheGoodThingThatEveryoneReallyMeans. NRRESTBTGTTERM. Hmm, that doesn't really roll off the tongue. Maybe Bett

We need a name for it then. Like NotReallyRESTButTheGoodThingThatEveryoneReallyMeans. NRRESTBTGTTERM. Hmm, that doesn't really roll off the tongue. Maybe BetterREST.

masklinn 10y ago
> Maybe BetterREST. It's not better and it still is not REST. Why don't you just call it what it is: HTTP. Or maybe HTTP-RPC if you want to be more specific.
- fnord123 10y ago
  To be clear, I think we're talking about REST without HATEOAS. And I think this is better, imo, as you can write your client knowing the protocol. I've not come across a convincing description of why HATEOAS is a good thing at all. And I say this as someone who thinks capability based design is a good thing. The reasons I have against it are that 1. I think it complicates the client because it needs to discover the api at runtime instead of just coding it up in a straight forward manner. 2. Receiving the capabilities seems to imply that these are the activities that can succeed. But they don't have to succeed. So you still have to handle errors. So you may as well know up front what the whole API is and handle errors, etc. 3. Dynamic apis are resistant to pipelining if you don't know what the next url will be. But I'm here to learn, so please hit me with a clue stick and explain why REST sans HATEOAS is not better.
  - icebraining 10y ago
    HATEOAS is a great concept, but we can only really take advantage of it if and when we move from this troglodyte era of APIs. The fact that we still consider normal to write new "client libraries" for each new service created is just absurd. Imagine if we had to write a new browser plugin for each new site we published - that's at the level we're at on APIs! To be more specific, HATEOAS is an essential component to comply with the Uniform Interface constraint of REST, which, as the dissertation describes, allows for decoupling and independent evolvability of the client and server. Since we still accept the idea that client libraries and the programs that use them should be completely coupled with the services they communicate with, and it's fine to force thousands or millions of developers to update their software because an URL on some service changed, HATEOAS doesn't feel particularly useful.
    - fnord123 10y ago
      >Imagine if we had to write a new browser plugin for each new site we published You mean like Electron applications? :P But seriously, I don't know what kind of clients you want to use, but if I want to store data on an object store, for example, I know what the verbs are. And if a new one is added, then at some point I need to change something on the client side to factor that in. Unless the server is also serving the UI as they do with web pages. <semi-rhetorical-strawman>If I'm using something like $AccountingProgram and my bank puts in a new possible action like "donate" to let me easily donate to charities which will return important information like deductions and the relevant fields, etc., then how might my accounting become aware of this new concept? </semi-rhetorical-strawman>. Maybe I'm too troglodyte to see it. My engineering senses are tingling with excitement that it would be cool that it automatically gets through to the client (without also being open to click/UI hijacking from shitheads) but I just don't see how it can happen.
    - smsm42 10y ago
      > Imagine if we had to write a new browser plugin for each new site we published Still happens all the time in mobile world. Not as obvious in Desktop word because the site is the app, you just download it each time anew instead of once. But there are Chrome plugins for many sites - Chrome web store has a lot of them. Most of the sites can work fine without them, nevertheless they exist.

We need a name for it then. Like NotReallyRESTButTheGoodThingThatEveryoneReallyMeans. NRRESTBTGTTERM. Hmm, that doesn't really roll off the tongue. Maybe BetterREST.

masklinn 10y ago

> Maybe BetterREST. It's not better and it still is not REST. Why don't you just call it what it is: HTTP. Or maybe HTTP-RPC if you want to be more specific.

fnord123 10y ago
To be clear, I think we're talking about REST without HATEOAS. And I think this is better, imo, as you can write your client knowing the protocol. I've not come across a convincing description of why HATEOAS is a good thing at all. And I say this as someone who thinks capability based design is a good thing. The reasons I have against it are that 1. I think it complicates the client because it needs to discover the api at runtime instead of just coding it up in a straight forward manner. 2. Receiving the capabilities seems to imply that these are the activities that can succeed. But they don't have to succeed. So you still have to handle errors. So you may as well know up front what the whole API is and handle errors, etc. 3. Dynamic apis are resistant to pipelining if you don't know what the next url will be. But I'm here to learn, so please hit me with a clue stick and explain why REST sans HATEOAS is not better.
- icebraining 10y ago
  HATEOAS is a great concept, but we can only really take advantage of it if and when we move from this troglodyte era of APIs. The fact that we still consider normal to write new "client libraries" for each new service created is just absurd. Imagine if we had to write a new browser plugin for each new site we published - that's at the level we're at on APIs! To be more specific, HATEOAS is an essential component to comply with the Uniform Interface constraint of REST, which, as the dissertation describes, allows for decoupling and independent evolvability of the client and server. Since we still accept the idea that client libraries and the programs that use them should be completely coupled with the services they communicate with, and it's fine to force thousands or millions of developers to update their software because an URL on some service changed, HATEOAS doesn't feel particularly useful.
  - fnord123 10y ago
    >Imagine if we had to write a new browser plugin for each new site we published You mean like Electron applications? :P But seriously, I don't know what kind of clients you want to use, but if I want to store data on an object store, for example, I know what the verbs are. And if a new one is added, then at some point I need to change something on the client side to factor that in. Unless the server is also serving the UI as they do with web pages. <semi-rhetorical-strawman>If I'm using something like $AccountingProgram and my bank puts in a new possible action like "donate" to let me easily donate to charities which will return important information like deductions and the relevant fields, etc., then how might my accounting become aware of this new concept? </semi-rhetorical-strawman>. Maybe I'm too troglodyte to see it. My engineering senses are tingling with excitement that it would be cool that it automatically gets through to the client (without also being open to click/UI hijacking from shitheads) but I just don't see how it can happen.
  - smsm42 10y ago
    > Imagine if we had to write a new browser plugin for each new site we published Still happens all the time in mobile world. Not as obvious in Desktop word because the site is the app, you just download it each time anew instead of once. But there are Chrome plugins for many sites - Chrome web store has a lot of them. Most of the sites can work fine without them, nevertheless they exist.