I've had the same feeling and finally came to a few conclusion that Fielding's REST architectural constraints lead to client applications that are required to utilize undefined URIs for performance gains. The reason true RESTful APIs are scarce as compared to HTTP/JSON APIs is due to API developers recognizing this issue and choosing to deal with it by making URIs part of the API contract. The REST community has offered no additional guidance or answers other than to point out (correctly) that HTTP/JSON APIs aren't truly RESTful. That is OK.
I just finished reading the paper and that’s what it looks like to me. It’s a CRUD interface w/ multiple implementations (proxy, cache, route, serialize, filesystem store, memory store), which they create pipelines out of using some syntactic sugar in the Objective-Smalltalk language. This syntactic sugar, discussed in their paper on ‘polymorphic identifiers’, allows you to use the same syntax for writing content to a file as you would writing to a key in a map or a field in an object. If you look at the pictures / tables in this paper, you get a general idea of what they are doing (e.g. replacing the filesystem store with a memory store while running tests). These dynamically dispatched processing pipelines are powerful, but can be hard to follow (which is true of dynamically dispatched processing pipelines in general). The power/obfuscation is multiplied by the convenient syntax of the language.
My opinion is that the actual innovation is the ‘polymorphic identifiers’ they introduced in their previous paper, which is definitely worth a read as my one line description of it can’t really do it justice. It’s kind of like being able to overload the assignment operator. Once you have that kind of feature, it’s sort of a no-brainer to say ‘Hey, all I/O (variables in memory, filesystems, etc) should use the same interface’.
This is really neat. In this space, is the normal metric 'atmospheric CO2 equivalent'? Is this just so they can normalize the affects of all the different things that cause warming into one unit for discussion purposes?
I was interested to see that too. Especially how it was tightly clustered with C. Maybe there are a lot of projects of C modules with a Python wrapper bringing them all together?
Just last Spring, he lent me his copy of "What Color is Your Parachute" and invited me into his office to discuss two job offers I was contemplating. He did all this after he passed by the CS library and saw me looking for something.
Can you explain a little more about what problem it's trying to solve and how it goes about doing that? I've read the architecture overview and it sounds a little bit like IPFS (ipfs.io). Is that correct?
I'm calling bullshit. Post a source for your examples. Also, the ABA and the AMA agree unions for lawyers and doctors. They have a government sanctioned monopoly on top level legal and medical talent. You can't even train lawyers and doctors without the approval of those organizations. The only reason those unions get a pass on the standard union rhetoric is because they are powerful while collar unions. Nobody with any credibility is saying the AMA residency matching is a detriment to the rights of workers, for example.
Who gets do define merit? Too many Jewish students were getting into Harvard in the early part of the 20th century, so the application process was changed.
So the university get a portion of each grant someone brings in? This may be naive, but I thought grant money was given to a person/project and that tuition paid for university stuff.
I have to agree. This gentleman seems a bit confused. I imagine a virtual livestock auction is something you'd want to utilize all the bandwidth you've paid your provider for and not risk being on a slow lane if the auction provider hasn't paid off your particular ISP. He seems to be advocating a market-based solution, but doesn't conceed that here is no competition.
Great article. If I'm understanding it correctly, it seems like the advantage comes from mapping your domain actions to the standard HTTP actions on each domain object. Once this is done, your API is simply the media types and the interaction with your service can be done through well-understood HTTP actions rather than learning a bunch of method calls as in an RPC approach. Correct?
I don't understand how it's possible to program to a true REST service given his final bullet point and one of his comments:
> A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]
> When I say hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user (or automaton) obtains choices and selects actions. [...] Hypertext does not need to be HTML on a browser. Machines can follow links when they understand the data format and relationship types.
If you're only supposed to start with an initial URI and there is no out-of-band communication, how is an automaton supposed to know what links to follow to reach the desired information? A person can do this by reading, reasoning about what they read, then following the appropriate link. Writing an automaton that can reason about anything that can fall under the initial URI seems equivalent to writing some kind of artificial intelligence.