4 ms·

The article writes: > Since everyone was using HTTP, and since everyone would keep using HTTP at least as a transport layer because of all the proxying and cac

by mcherm 5y ago

The article writes: > Since everyone was using HTTP, and since everyone would keep using HTTP at least as a transport layer because of all the proxying and caching support, the simplest possible thing to do was just rely on HTTP’s existing semantics. So that’s what they did. They could have called their approach Fuck It, Overload HTTP (FIOH), and that would have been an accurate name First of all, I fully agree with this article. I lived through this transition and my own reasoning is well as that of basically everyone I talked to was really just that the existing infrastructure was overly complicated, while "just passed some JSON over HTTP" was easy. I do, however, want to disagree with one point quoted above. The proxying and caching support were not the reasons why FIOH was based on HTTP. The reason was firewalls. At first, almost all of the things I built and almost all of the RESTful APIs I saw published, were really just some form of remote procedure call. Caching was supported in theory but hardly ever used in practice. However, it was policy pretty much everywhere to have firewalls that blocked traffic to most ports other than 80 and 443. The more advanced firewalls also verify that traffic over those ports was actually HTTP traffic. So it wasn't possible to build any kind of an API that wasn't based on HTTP -- it would have been impossible to deploy and use without getting permission from the firewall and security teams on both the client and server and of the connection.

fieldcny 5y ago
This was my experience as well, trying to convinced enterprise security folks to let new protocols through firewalls was nearly impossible. The difficulty was exponentiated for api/service calls inbound to the organization. SOAP services, even though they went over http, had to go through special inspection devices because XML parsing libraries were so complex and prone to parsing issues and security vulns.
- voakbasda 5y ago
  > SOAP services, even though they went over http, had to go through special inspection devices because XML parsing libraries were so complex and prone to parsing issues and security vulns. So did the person who ordered that inspection device realize that the SOAP streams under inspection would be examined using a set of XML parsing libraries that are complex and prone to vulnerabilities? Seems like this setup just creates another device that must be maintained. Perhaps the solution would be to use another machine to inspect the inspection devices. Turtles all the way down.
RegW 5y ago
I'd say the adoption of HTTP protocols was certainly driven by firewalls. This was just as true for SOAP as it was REST. However, in earlier times caching was also important, and this is one of the places where REST beat SOAP. However, the caching idea seems to have been lost by most developers now. For high volume sites we would cache at multiple levels. At the load balancer, on the CDN or in the browser - depending on how public/user-centric the data was. You would not expect a browser to return to the server every time for a 1 pixel spacer gif (oh the glory days), and you wouldn't expect it to keep retriving the user's name for the top of each otherwise static page. However, things changed - the consumers of APIs were no longer browsers and the internet just got faster and faster. I can understand why developers just decided to forget about caching. This is probably why most developers I now encounter just can't understand why the thing at the end of a GET or PUT url should be a "thing" not an operation.
- bobthebuilders 5y ago
  > understand why the thing at the end of a GET or PUT url should be a "thing" not an operation what do you mean by this?
  - RegW 5y ago
    The URL identifies an entity. In the old static website days this meant a file - a html file or an image on a file system. With REST, the idea was to create a virtual filesystem and take advantage of the HTTP infrastructure already in place with regards to caching etc. So often when I get involved in "REST" projects, I find URLs that include words like "update" or "add", or where the GET returns JSON with a completely different shape to that the PUT accepts. Does it matter? If you don't cache anything - probably not, but it isn't REST as it was understood.
snowwrestler 5y ago
The ironic outcome here was that everything moved to run over 80 and 443 and so traditional firewalls, by being so locked down, became basically irrelevant to modern information security. They just became NAT machines, and security practice moved up one layer of the network stack along with everything else.

by mcherm 5y ago

fieldcny 5y ago

This was my experience as well, trying to convinced enterprise security folks to let new protocols through firewalls was nearly impossible. The difficulty was exponentiated for api/service calls inbound to the organization. SOAP services, even though they went over http, had to go through special inspection devices because XML parsing libraries were so complex and prone to parsing issues and security vulns.

voakbasda 5y ago
> SOAP services, even though they went over http, had to go through special inspection devices because XML parsing libraries were so complex and prone to parsing issues and security vulns. So did the person who ordered that inspection device realize that the SOAP streams under inspection would be examined using a set of XML parsing libraries that are complex and prone to vulnerabilities? Seems like this setup just creates another device that must be maintained. Perhaps the solution would be to use another machine to inspect the inspection devices. Turtles all the way down.

RegW 5y ago

I'd say the adoption of HTTP protocols was certainly driven by firewalls. This was just as true for SOAP as it was REST. However, in earlier times caching was also important, and this is one of the places where REST beat SOAP. However, the caching idea seems to have been lost by most developers now. For high volume sites we would cache at multiple levels. At the load balancer, on the CDN or in the browser - depending on how public/user-centric the data was. You would not expect a browser to return to the server every time for a 1 pixel spacer gif (oh the glory days), and you wouldn't expect it to keep retriving the user's name for the top of each otherwise static page. However, things changed - the consumers of APIs were no longer browsers and the internet just got faster and faster. I can understand why developers just decided to forget about caching. This is probably why most developers I now encounter just can't understand why the thing at the end of a GET or PUT url should be a "thing" not an operation.

bobthebuilders 5y ago
> understand why the thing at the end of a GET or PUT url should be a "thing" not an operation what do you mean by this?
- RegW 5y ago
  The URL identifies an entity. In the old static website days this meant a file - a html file or an image on a file system. With REST, the idea was to create a virtual filesystem and take advantage of the HTTP infrastructure already in place with regards to caching etc. So often when I get involved in "REST" projects, I find URLs that include words like "update" or "add", or where the GET returns JSON with a completely different shape to that the PUT accepts. Does it matter? If you don't cache anything - probably not, but it isn't REST as it was understood.

snowwrestler 5y ago

The ironic outcome here was that everything moved to run over 80 and 443 and so traditional firewalls, by being so locked down, became basically irrelevant to modern information security. They just became NAT machines, and security practice moved up one layer of the network stack along with everything else.