I can't stand the "blog post as conversation" format. It's fine if you're quoting a conversation for one or two paragraphs, but for something this long you should do me (the reader) the courtesy of speaking directly to me.<p>Also this is giving way too much credit for the creation of the URL. The format of the URL is not some miracle, genius insight. It is a natural result of network computing, and similar descriptors of how to find a file on a remote system had existed previously for ages.
It's a great blog post, but it has been posted numerous times on HN. I don't want to rant or anything, but I think we should start searching before posting. Please correct me, if I am wrong.<p>cheers
<a href="http://news.ycombinator.com/item?id=763570" rel="nofollow">http://news.ycombinator.com/item?id=763570</a>
<a href="http://news.ycombinator.com/item?id=3396910" rel="nofollow">http://news.ycombinator.com/item?id=3396910</a>
<a href="http://news.ycombinator.com/item?id=5186774" rel="nofollow">http://news.ycombinator.com/item?id=5186774</a>
What do you think about the separation of Web sites and Web services (so-called APIs)? Shouldn't the Web site <i>be</i> the Web service, and offer multiple representations of its endpoints?<p>As a trivial example, consider that I have a blog located at the URIL <a href="http://www.example.org/posts/" rel="nofollow">http://www.example.org/posts/</a><p>If I were to offer an API to other developers, I would have two options: 1) serve posts as `application/json` at the URI <a href="http://www.example.org/api/v1/posts" rel="nofollow">http://www.example.org/api/v1/posts</a> ; 2) serve both `text/html` and a `application/json` representations at the same URI <a href="http://www.example.org/posts" rel="nofollow">http://www.example.org/posts</a> , handling the desired mime-type and API version in the 'Accept' field of the HTTP request.<p>Which approach is better?
Yes, and we also have XML, the Academically Correct and proven-in-the-field way to represent all entities.<p>I get the "URLs are nouns" metaphor, but I don't think it needs any additional promotion or particularly favors HTTP over whatever else might emerge.
Correct me if I am wrong here. So, instead of the eloquent method of using GET, POST and PUT on resources, the current practice is about the programmer writing custom parsers to get the information they want and then use them accordingly.
Isn't representation of resources what the semantic web is supposed to be about? if I wanted to make someone understand the semantic web I would say something like this,<p>ontologies are data with corresponding metadata about everything on a domain or site.<p>These ontologies allow the data to be parsed automatically, i.e sites like amazon could just make their data available as ontologies and third party sites could "read through the sites for us". These third party sites serve as a portal from where we could ask for what we want and they would in turn look through the sites available (eBay, amazon etc) using the ontologies and get the best deal for us.
He uses four metaphors to help explain this:<p>1. Cleaning
2. A coffee table
3. Shopping
4. A school<p>So was he explaining this to his wife in the 1970s? Because REST over HTTP didn't even exist until the 90s.
> Wife: You mean "http" like the beginning of what I type into the browser?<p>What browser does she use? It wasn't required to type that anymore for ages already :)