Indeed. I feel this article misses two important things, though. One, the paper is very well written and easy to read, especially considering it’s a doctorate dissertation (and it’s available in perfectly reasonable html, not only as a Pdf).
Second, I’d argue that chapter 3.5 on mobile code style covers modern front-end driven web apps very well (and, no, they’re not REST applications) :
As someone who read the dissertation very early in their engineering life, I love seeing this summary, including all the quirky “$” abbreviations for “cache”.
My biggest learning from the dissertation was the approach that architecture is a set of voluntary constraints to make expectations and thinking even possible. I have definitely made that experience when we were building a very fast dynamic frontend based on sub-resource caching, that had SPA-like behaviour, but with extremely quick load times. It was much important to know that all backend services follow a set of assumptions to easily make page assembly possible.
I’m not sure though if I would pain such a bleak picture. REST as practiced has definitely gone through multiple iterations. At first, the tendency to serve every resource in multiple formats (XML, JSON, even HTML fragments). Later, things like JSON-API, which do follow the link model described.
At first, the tendency to serve every resource in multiple formats (XML, JSON, even HTML fragments).
I really like the idea of multiple formats. REST ≠ JSON! Indeed, I would love to see wider support for content negotiation and the ability to upgrade to more reasonable data representations.
Most frameworks allow content negotiation with an API, e.g. Rails respond_with. It’s more that multiple formats are a chore to build on the development side.
I have an “Intro to REST” talk where I walk the audience through the history of network computing, in particular as illustrated by the design choices of version control systems of the day, mainframes and terminals, Novell network drives, RCS, CVS, svn, git…
You can see elements of all the architectural design tradeoffs in all of these.
But to me the critical insight that Fielding had that seems hardest for people to grasp… is the importance of Anarchic Scalability.
The concept is an anathema to the corporate apparatchik… but drives everything about the web.
the backend only talks to clients that the engineering team has full control over.
The alternative often is less palatable….
The backend only talks to THE single bespoke connascently coupled client that the engineering team won’t relinquish control of, irrespective of what the customers needs are. And changing the client or the server will inevitably cause the other to break.
Purity aside what I actually come across (and mostly what I design) is influenced by Fielding’s ideas but is actually HTTP-RPC with json or protobuf. And honestly that’s fine because I remember the pain that was proprietary binary protocols, or CORBA, SOAP/XML, the odd instance of Thrift, sometimes finding WSDL, and writing bespoke clients. I’m still writing bespoke but at least there’s some OpenAPI specs to work from and test against and the general expectation that GET doesn’t update and that POST and PUT do. It sucks less and that’s a good thing.
RPC calls are a model to be considered for everything where all the concerns that make REST great (transparent caching, repeatability and such) aren’t such a great concern. For example, a lot of APIs at cloud providers rarely fit the CRUD model very well…
I actually spend some time in a research department investigating both models and we found that even mixed models can make sense (e.g. having “List all machines” and similar exposed more REST-like, while configuration is more RPC-like). They run into the danger though to be mapped to OO in the back, which they just aren’t.
I still highly recommend reading the REST dissertation for naming all of those concerns and actually encouraging you to investigate whether you truly have them.
I still highly recommend reading the REST dissertation for naming all of those concerns and actually encouraging you to investigate whether you truly have them.
Re-read. But yes, it’s been years since I read it.
Indeed. I feel this article misses two important things, though. One, the paper is very well written and easy to read, especially considering it’s a doctorate dissertation (and it’s available in perfectly reasonable html, not only as a Pdf).
Second, I’d argue that chapter 3.5 on mobile code style covers modern front-end driven web apps very well (and, no, they’re not REST applications) :
https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_5
As someone who read the dissertation very early in their engineering life, I love seeing this summary, including all the quirky “$” abbreviations for “cache”.
My biggest learning from the dissertation was the approach that architecture is a set of voluntary constraints to make expectations and thinking even possible. I have definitely made that experience when we were building a very fast dynamic frontend based on sub-resource caching, that had SPA-like behaviour, but with extremely quick load times. It was much important to know that all backend services follow a set of assumptions to easily make page assembly possible.
I’m not sure though if I would pain such a bleak picture. REST as practiced has definitely gone through multiple iterations. At first, the tendency to serve every resource in multiple formats (XML, JSON, even HTML fragments). Later, things like JSON-API, which do follow the link model described.
I really like the idea of multiple formats. REST ≠ JSON! Indeed, I would love to see wider support for content negotiation and the ability to upgrade to more reasonable data representations.
Most frameworks allow content negotiation with an API, e.g. Rails respond_with. It’s more that multiple formats are a chore to build on the development side.
I have an “Intro to REST” talk where I walk the audience through the history of network computing, in particular as illustrated by the design choices of version control systems of the day, mainframes and terminals, Novell network drives, RCS, CVS, svn, git…
You can see elements of all the architectural design tradeoffs in all of these.
But to me the critical insight that Fielding had that seems hardest for people to grasp… is the importance of Anarchic Scalability.
The concept is an anathema to the corporate apparatchik… but drives everything about the web.
Is there a video of it?
Unfortunately not, but I have the slides…..Ahhh. Somewhere. Probably on my home laptop doesn’t seem to be on my desktop.
The alternative often is less palatable….
The backend only talks to THE single bespoke connascently coupled client that the engineering team won’t relinquish control of, irrespective of what the customers needs are. And changing the client or the server will inevitably cause the other to break.
Purity aside what I actually come across (and mostly what I design) is influenced by Fielding’s ideas but is actually HTTP-RPC with json or protobuf. And honestly that’s fine because I remember the pain that was proprietary binary protocols, or CORBA, SOAP/XML, the odd instance of Thrift, sometimes finding WSDL, and writing bespoke clients. I’m still writing bespoke but at least there’s some OpenAPI specs to work from and test against and the general expectation that GET doesn’t update and that POST and PUT do. It sucks less and that’s a good thing.
RPC calls are a model to be considered for everything where all the concerns that make REST great (transparent caching, repeatability and such) aren’t such a great concern. For example, a lot of APIs at cloud providers rarely fit the CRUD model very well…
I actually spend some time in a research department investigating both models and we found that even mixed models can make sense (e.g. having “List all machines” and similar exposed more REST-like, while configuration is more RPC-like). They run into the danger though to be mapped to OO in the back, which they just aren’t.
I still highly recommend reading the REST dissertation for naming all of those concerns and actually encouraging you to investigate whether you truly have them.
Re-read. But yes, it’s been years since I read it.