4 ms·

Hey, I’m kinda new to this area, can you show with examples what the differences are? I read the article, he does a lot of explaining but doesn’t do much showin

by vxNsr 4y ago

Hey, I’m kinda new to this area, can you show with examples what the differences are? I read the article, he does a lot of explaining but doesn’t do much showing. Like why is a specific api more RPC and why a different one is a perfectly constructed REST api?

recursivedoubts 4y ago
REST was the term Roy Fielding coined as description of the original web architecture. The big distinguishing feature of REST-ful systems vs. non-REST-ful systems was something called the uniform interface, where clients had zero knowledge about a given server's API surface beyond a URL entry point. Everything after that was encoded in hypermedia, giving us the term "Hypermedia As The Engine of Application State" (HATEOAS). Here is an article I wrote on it: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ RPC-style APIs require shared knowledge about a given end point: what arguments it expects, what data it returns, etc. Unfortunately, for historical reasons, we've come to call all HTTP JSON APIs "REST APIs". It's actually pretty funny.
- jackling 4y ago
  Thanks! I was really confused with this topic, and your post cleared things up. But from what I gather, proper REST API's wouldn't pair nicely with modern day UI development. Maybe this is because I usually work with APIs that wouldn't be considered restful (from my understanding, my company's public API is here [https://developer.veevavault.com/api/22.1/ https://developer.veevavault.com/api/22.1/]), I have a hard time seeing how a modern React webapp would parse the HTTP form response given in your article.
  - recursivedoubts 4y ago
    That's right, REST concepts are largely wasted on modern SPA applications, which are fundamentally RPC-style clients. Instead, REST should be used in its original context: hypermedia clients (browsers) exchanging hypermedia (HTML) with the server. I have written an alternative front end library that takes this exact approach: https://htmx.org https://htmx.org Some more essays on the topic: https://htmx.org/essays/spa-alternative/ https://htmx.org/essays/spa-alternative/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/
    - jackling 4y ago
      Thank you! This has been a point of confusion for me for a while, maybe I should get around to reading Roy's dissertation. Your post did clear things up :)

by vxNsr 4y ago

recursivedoubts 4y ago

REST was the term Roy Fielding coined as description of the original web architecture. The big distinguishing feature of REST-ful systems vs. non-REST-ful systems was something called the uniform interface, where clients had zero knowledge about a given server's API surface beyond a URL entry point. Everything after that was encoded in hypermedia, giving us the term "Hypermedia As The Engine of Application State" (HATEOAS). Here is an article I wrote on it: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ RPC-style APIs require shared knowledge about a given end point: what arguments it expects, what data it returns, etc. Unfortunately, for historical reasons, we've come to call all HTTP JSON APIs "REST APIs". It's actually pretty funny.

jackling 4y ago
Thanks! I was really confused with this topic, and your post cleared things up. But from what I gather, proper REST API's wouldn't pair nicely with modern day UI development. Maybe this is because I usually work with APIs that wouldn't be considered restful (from my understanding, my company's public API is here [https://developer.veevavault.com/api/22.1/ https://developer.veevavault.com/api/22.1/]), I have a hard time seeing how a modern React webapp would parse the HTTP form response given in your article.
- recursivedoubts 4y ago
  That's right, REST concepts are largely wasted on modern SPA applications, which are fundamentally RPC-style clients. Instead, REST should be used in its original context: hypermedia clients (browsers) exchanging hypermedia (HTML) with the server. I have written an alternative front end library that takes this exact approach: https://htmx.org https://htmx.org Some more essays on the topic: https://htmx.org/essays/spa-alternative/ https://htmx.org/essays/spa-alternative/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/
  - jackling 4y ago
    Thank you! This has been a point of confusion for me for a while, maybe I should get around to reading Roy's dissertation. Your post did clear things up :)