3 ms·

> Do you have any resources showing what an API client for a "true REST" system would look like? You are using one, this very moment, as you read this comment.

> Do you have any resources showing what an API client for a "true REST" system would look like? You are using one, this very moment, as you read this comment. Fielding's concept of "REST" was not a prescription for a new type of RPC system; it was a description of the architecture of the web as it existed at the time. The "computer application that has no context beyond an entry URL and a media type" is simply a web browser.

Jasper_ 3y ago
Sure, but how is that a helpful concept in any way? If I started calling my operating system an "ALLOCBAG" and made a dissertation talking about "The ALLOCBAG Principle" you can't really deny me that it's a thing that exists ("ALLOCBAGs are all around you! You're using one I'd right now", I'd say), but it's not really advancing the state of discussion here. Similarly, rebadging "a client/server system that does a thing when you interact with the client" as "REST" (yes, I know there's a bit more to the definition) doesn't seem useful or helpful. So out it goes, in favor of the one that's talking about a style of API design. Roy Fielding designed the Adobe Experience Manager API according to his idea of REST [0]. I don't think the resulting API was remarkably noteworthy. [1] [0] https://www.slideshare.net/AEMHub2014/rest-in-aem-by-roy-fielding https://www.slideshare.net/AEMHub2014/rest-in-aem-by-roy-fie... [1] https://experienceleague.adobe.com/docs/experience-manager-65/content/assets/extending/mac-api-assets.html https://experienceleague.adobe.com/docs/experience-manager-6...
lolinder 3y ago
Human UIs like HN are the only example I've ever seen that's compelling. But when you refer to it as a RESTful API (TFA uses "APIs" 31 times) you're not talking about a UI, you're talking about an Application Programming Interface, which is explicitly defined as an interface by which computers talk to each other. If REST just plain shouldn't be used in APIs then that's a fine argument to make, but we should start calling for RESTful UIs and start pointing out that a RESTful API is an oxymoron. We shouldn't be pushing for integrating HATEOAS into APIs.

Jasper_ 3y ago

Sure, but how is that a helpful concept in any way? If I started calling my operating system an "ALLOCBAG" and made a dissertation talking about "The ALLOCBAG Principle" you can't really deny me that it's a thing that exists ("ALLOCBAGs are all around you! You're using one I'd right now", I'd say), but it's not really advancing the state of discussion here. Similarly, rebadging "a client/server system that does a thing when you interact with the client" as "REST" (yes, I know there's a bit more to the definition) doesn't seem useful or helpful. So out it goes, in favor of the one that's talking about a style of API design. Roy Fielding designed the Adobe Experience Manager API according to his idea of REST [0]. I don't think the resulting API was remarkably noteworthy. [1] [0] https://www.slideshare.net/AEMHub2014/rest-in-aem-by-roy-fielding https://www.slideshare.net/AEMHub2014/rest-in-aem-by-roy-fie... [1] https://experienceleague.adobe.com/docs/experience-manager-65/content/assets/extending/mac-api-assets.html https://experienceleague.adobe.com/docs/experience-manager-6...

lolinder 3y ago

Human UIs like HN are the only example I've ever seen that's compelling. But when you refer to it as a RESTful API (TFA uses "APIs" 31 times) you're not talking about a UI, you're talking about an Application Programming Interface, which is explicitly defined as an interface by which computers talk to each other. If REST just plain shouldn't be used in APIs then that's a fine argument to make, but we should start calling for RESTful UIs and start pointing out that a RESTful API is an oxymoron. We shouldn't be pushing for integrating HATEOAS into APIs.