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.
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.