4 ms·

This piece and conversation makes me sad. As someone who both wrote a (client-side) web browser in the 1990s and at the time also built server side HTTP system

This piece and conversation makes me sad. As someone who both wrote a (client-side) web browser in the 1990s and at the time also built server side HTTP systems, the piece gets it almost entirely wrong, and the degree of misguidedness in the HN comments is almost worse. But I guess that is how things go. Sigh. The competitor to ReST (representational state transfer) was not SOAP. It was and is RPC, and by extension, object oriented languages. The brilliant recognition Roy had, the genius of ReST, is that most systems are about data, not behavior, and solving for distributed system reliability was mostly about moving data around, statelessly. At the time, distributed systems were not the thing they are today, but what people were doing was informally called distributed objects- things that have state and behavior, the lifecycles of which are manageable remotely. Incredibly complicated stuff, failed all the time. You can see a good example of this in Java RMI, which was still shipping in Java until recently. The term "agent" has been deeply overloaded but it was also applied here. I think there is a good argument there is a direct line between Roy's insights, as expressed in ReST, and functional programming and the immutability revolution, and also the CAP theorem. The system design principles are exactly the same. Hope that story gets a proper telling some day.

austincheney 6y ago
In order to better appreciate the idea you have to understand the context of addressing during that time. Addressing was a major factor in the architecture implemented at the time, for example CGI which executed dynamic scripts at the web server from a known fixed location. https://en.m.wikipedia.org/wiki/Common_Gateway_Interface https://en.m.wikipedia.org/wiki/Common_Gateway_Interface The web was invented so that supporting documents in research can be addressed via hyperlink, as opposed to just by citation, for more fluid understand of research material and technical documents. The hyperlink address of those supporting documents indicated where in the system those documents reside and that form of addressing was the basis of the URL. In later practice the URL would denote a service own via domain and a path on that server where documents reside. https://en.m.wikipedia.org/wiki/Uniform_Resource_Identifier https://en.m.wikipedia.org/wiki/Uniform_Resource_Identifier As the idea for web standards began to emerge in the mid 90s there came the idea of the URI. URI does not represent a location, as in a URL, but instead a unique identity. The idea of URI became a parent taxonomy to existing things like URL, URN, ISBN, and so forth. The idea for URI was influenced by the idea of email addressing which was at the time already in wide use as both a unique identifier and an address location. An example of this idea worked directly into a technology is RDF. https://en.m.wikipedia.org/wiki/Resource_Description_Framework https://en.m.wikipedia.org/wiki/Resource_Description_Framewo... Fielding was deeply involved in the work of addressing as he was co-authoring several of the related RFCs that would in several years get rolled up in RFC 3986, 5 years after the dissertation. The most influential idea introduced by REST is that as an architectural style an address can serve as an idea scheme instead of just document location on a distant server. Nobody cares where on a server a document resides so long as the address returns the intended content. Bigger still is that an address does not have to resolve or return anything to provide a variety of functional uses.
- jonahbenton 6y ago
  Yes, CGI is a good call out, from architectural style perspective it is equivalent to RPC. And yes URL/URI became substantially Roy's work, an idealized digital reference syntax, as was also the fact that what you got at a particular address- if you were to get anything- was data- maybe structured as a media type. There was no commitment to behavior or semantics. Just data. What I never got a complete sense of, from reading the docs and mailing list convos at the time, is how much Roy came to HTTP with the data-driven perspective, vs how much he absorbed from what were initially TBL decisions- organized around sharing documents and data- and from the presence of Gopher and FTP- dominant protocols at the time and both entirely data driven. And of course going back further- Ted Nelson, Vannevar Bush and others- their relevant work was almost entirely in the data driven vein.
TedDoesntTalk 6y ago
> Incredibly complicated stuff, failed all the time. You can see a good example of this in Java RMI, which was still shipping in Java until recently Agreed. Java EJBs,specifically distributed session beans, were the incumbent, along with DCOM objects on the Windows side. Also, in my experience, I don’t ever recall anyone using RMI directly. EJBs were used much more frequently than direct RMI. However, IIRC distributed session beans used RMI under the hood. We also did plain XML over HTTP using Internet Explorer’s XMLHTTPRequest object in JavaScript. Not SOAP, just custom xml. But that was client side...
smaudet 6y ago
While I think we all recognize that the approach, to handle data and not live objects, is different, you seem to have missed the core objections, which are that REST is and was widely misunderstood and FIOH might as well be the true protocol in widespread use today. The irony is that this 'REST' is used now in part to support lifecycle management of live objects, in the browser, but this has architectural implications. Further, dogged adherence to arbitrary 'REST' or FIOH explains the growing popularity of a growing number of non Restful http protocol extensions like websockets, webrtc, graphql, as people search for rpc alternatives for things REST was never intended for. This seems to be a pretty valid criticism of the state of industry 'REST'.
goto11 6y ago
People are far to concerned about whether an API is "true REST" or not, as if being "REST" is some kind of mark of quality. But nobody have yet made a convincing case that HATEOAS is even particularly useful for machine-to-machine integration. But a number of properties of REST are very useful for API's, for example the focus on data and URL's and the explicit distinction between methods which are safe and methods which have side effects. The conversation should be about what patterns help us build useful API's, not about canonical or heretical REST.
- jonahbenton 6y ago
  Yeah. Side note, you probably know but OWL and RDF and related semantic data and graph model standards are "machine-to-machine" usable and have a clear lineage to Roy's work. HATEOAS was a stab in that direction, but insufficient.
throw_m239339 6y ago
Actually, you agree with half of the people here who claim that REST wasn't about designing API. Because it isn't. The other half who claim that REST is an architectural style for API still don't understand what that dissertation was about, and it wasn't about 2 web apps communicating with each others. We already have plenty of protocols for that, REST isn't one.
- jonahbenton 6y ago
  Excellent quote- "We already have plenty of protocols, REST isn't one"
jogjayr 6y ago
> there is a direct line between Roy's insights, as expressed in ReST, and functional programming and the immutability revolution, and also the CAP theorem. I know (at least superficially) what these things are, but I don't quite see the connection. Do you mind explaining please? It certainly sounds like a very interesting subject for a blog post or two.
- jonahbenton 6y ago
  It is worth a blog post, one unfortunately that I don't have time to write. Roy (and others) rewrote/enhanced early TBL HTTP specs, and then Roy wrote the thesis describing the thinking behind the new spec, defining an "architectural style" called ReST (Representational State Transfer). So the thesis is in effect a defense of work already done, and an expansion and consolidation of thinking behind the motivation. The short version is that ReST is about the primacy of data, and of not making application level semantics into a network protocol. All you can do with HTTP are abstract CRUD operations- the fact that those operations may entail complicated application-level behavior behind the server to update a data model or send an email or generate an image or whatever- are irrelevant. (RPC/gRPC is an anti-pattern / counter argument to this.) Functional programming is also about the primacy of data. Data, rather than objects, matter. Work in terms of generic functions explicitly applied to immutable data, creating new data, rather than application-and context-specific mutations implicitly applied to objects, subtly transforming the state of the object, serving the interest of encapsulation, but in practice obscuring and confusing. HTTP's URIs- references to data- small number of "methods", emphasis on content and media types- versionable data structures, not classes- and the distinction between idempotent and non-idempotent write operations- a distinction almost never made in the interfaces of objects- comes from the same motivation as that which leads to functional programming. This is a little hard to see now but distributed objects- encapsulated state and behavior- were a huge thing in the early days of the Internet. Objects don't scale. Distinct functions and data do. ReST and HTTP enshrine this. Finally, the CAP "theorem" points out that distributed systems have to choose between consistency and availability in the face of network partitions. Note that CAP had not been coined when Roy did his thesis work. He nevertheless incorporated into ReST- with HTTP cache semantics- the key implications of CAP. HTTP cache headers and HTTP response codes allow for both consistency and availability to be tightly defined. HTTP cache is taken for granted now with URIs and browser caches and CDNs and cache-busting and so forth, but in retrospect should be considered revolutionary. A strong version of this statement is that CAP is a mere footnote to ReST. Hope that helps. Cheers.

austincheney 6y ago

In order to better appreciate the idea you have to understand the context of addressing during that time. Addressing was a major factor in the architecture implemented at the time, for example CGI which executed dynamic scripts at the web server from a known fixed location. https://en.m.wikipedia.org/wiki/Common_Gateway_Interface https://en.m.wikipedia.org/wiki/Common_Gateway_Interface The web was invented so that supporting documents in research can be addressed via hyperlink, as opposed to just by citation, for more fluid understand of research material and technical documents. The hyperlink address of those supporting documents indicated where in the system those documents reside and that form of addressing was the basis of the URL. In later practice the URL would denote a service own via domain and a path on that server where documents reside. https://en.m.wikipedia.org/wiki/Uniform_Resource_Identifier https://en.m.wikipedia.org/wiki/Uniform_Resource_Identifier As the idea for web standards began to emerge in the mid 90s there came the idea of the URI. URI does not represent a location, as in a URL, but instead a unique identity. The idea of URI became a parent taxonomy to existing things like URL, URN, ISBN, and so forth. The idea for URI was influenced by the idea of email addressing which was at the time already in wide use as both a unique identifier and an address location. An example of this idea worked directly into a technology is RDF. https://en.m.wikipedia.org/wiki/Resource_Description_Framework https://en.m.wikipedia.org/wiki/Resource_Description_Framewo... Fielding was deeply involved in the work of addressing as he was co-authoring several of the related RFCs that would in several years get rolled up in RFC 3986, 5 years after the dissertation. The most influential idea introduced by REST is that as an architectural style an address can serve as an idea scheme instead of just document location on a distant server. Nobody cares where on a server a document resides so long as the address returns the intended content. Bigger still is that an address does not have to resolve or return anything to provide a variety of functional uses.

jonahbenton 6y ago
Yes, CGI is a good call out, from architectural style perspective it is equivalent to RPC. And yes URL/URI became substantially Roy's work, an idealized digital reference syntax, as was also the fact that what you got at a particular address- if you were to get anything- was data- maybe structured as a media type. There was no commitment to behavior or semantics. Just data. What I never got a complete sense of, from reading the docs and mailing list convos at the time, is how much Roy came to HTTP with the data-driven perspective, vs how much he absorbed from what were initially TBL decisions- organized around sharing documents and data- and from the presence of Gopher and FTP- dominant protocols at the time and both entirely data driven. And of course going back further- Ted Nelson, Vannevar Bush and others- their relevant work was almost entirely in the data driven vein.

TedDoesntTalk 6y ago

> Incredibly complicated stuff, failed all the time. You can see a good example of this in Java RMI, which was still shipping in Java until recently Agreed. Java EJBs,specifically distributed session beans, were the incumbent, along with DCOM objects on the Windows side. Also, in my experience, I don’t ever recall anyone using RMI directly. EJBs were used much more frequently than direct RMI. However, IIRC distributed session beans used RMI under the hood. We also did plain XML over HTTP using Internet Explorer’s XMLHTTPRequest object in JavaScript. Not SOAP, just custom xml. But that was client side...

smaudet 6y ago

While I think we all recognize that the approach, to handle data and not live objects, is different, you seem to have missed the core objections, which are that REST is and was widely misunderstood and FIOH might as well be the true protocol in widespread use today. The irony is that this 'REST' is used now in part to support lifecycle management of live objects, in the browser, but this has architectural implications. Further, dogged adherence to arbitrary 'REST' or FIOH explains the growing popularity of a growing number of non Restful http protocol extensions like websockets, webrtc, graphql, as people search for rpc alternatives for things REST was never intended for. This seems to be a pretty valid criticism of the state of industry 'REST'.

goto11 6y ago

People are far to concerned about whether an API is "true REST" or not, as if being "REST" is some kind of mark of quality. But nobody have yet made a convincing case that HATEOAS is even particularly useful for machine-to-machine integration. But a number of properties of REST are very useful for API's, for example the focus on data and URL's and the explicit distinction between methods which are safe and methods which have side effects. The conversation should be about what patterns help us build useful API's, not about canonical or heretical REST.

jonahbenton 6y ago
Yeah. Side note, you probably know but OWL and RDF and related semantic data and graph model standards are "machine-to-machine" usable and have a clear lineage to Roy's work. HATEOAS was a stab in that direction, but insufficient.

throw_m239339 6y ago

Actually, you agree with half of the people here who claim that REST wasn't about designing API. Because it isn't. The other half who claim that REST is an architectural style for API still don't understand what that dissertation was about, and it wasn't about 2 web apps communicating with each others. We already have plenty of protocols for that, REST isn't one.

jonahbenton 6y ago
Excellent quote- "We already have plenty of protocols, REST isn't one"

jogjayr 6y ago

> there is a direct line between Roy's insights, as expressed in ReST, and functional programming and the immutability revolution, and also the CAP theorem. I know (at least superficially) what these things are, but I don't quite see the connection. Do you mind explaining please? It certainly sounds like a very interesting subject for a blog post or two.

jonahbenton 6y ago
It is worth a blog post, one unfortunately that I don't have time to write. Roy (and others) rewrote/enhanced early TBL HTTP specs, and then Roy wrote the thesis describing the thinking behind the new spec, defining an "architectural style" called ReST (Representational State Transfer). So the thesis is in effect a defense of work already done, and an expansion and consolidation of thinking behind the motivation. The short version is that ReST is about the primacy of data, and of not making application level semantics into a network protocol. All you can do with HTTP are abstract CRUD operations- the fact that those operations may entail complicated application-level behavior behind the server to update a data model or send an email or generate an image or whatever- are irrelevant. (RPC/gRPC is an anti-pattern / counter argument to this.) Functional programming is also about the primacy of data. Data, rather than objects, matter. Work in terms of generic functions explicitly applied to immutable data, creating new data, rather than application-and context-specific mutations implicitly applied to objects, subtly transforming the state of the object, serving the interest of encapsulation, but in practice obscuring and confusing. HTTP's URIs- references to data- small number of "methods", emphasis on content and media types- versionable data structures, not classes- and the distinction between idempotent and non-idempotent write operations- a distinction almost never made in the interfaces of objects- comes from the same motivation as that which leads to functional programming. This is a little hard to see now but distributed objects- encapsulated state and behavior- were a huge thing in the early days of the Internet. Objects don't scale. Distinct functions and data do. ReST and HTTP enshrine this. Finally, the CAP "theorem" points out that distributed systems have to choose between consistency and availability in the face of network partitions. Note that CAP had not been coined when Roy did his thesis work. He nevertheless incorporated into ReST- with HTTP cache semantics- the key implications of CAP. HTTP cache headers and HTTP response codes allow for both consistency and availability to be tightly defined. HTTP cache is taken for granted now with URIs and browser caches and CDNs and cache-busting and so forth, but in retrospect should be considered revolutionary. A strong version of this statement is that CAP is a mere footnote to ReST. Hope that helps. Cheers.