When did the first "REST"-model and friendly URL web technology come to be?

Question

Everyone knows that the "current" way to do things is to have user-readable URLs. Like:

http://example.com/blog/edit/1234

Rather than:

http://example.com/blog.php?action=edit&id=1234

When exactly did people start making web technologies handling this though? I remember in the dark ages of the early 2000s, I don't remember ever seeing a friendly URL. In fact, I think Stackoverflow (in 2008/9) may have been the first time I noticed them.

When exactly did this become so popular, and what were the first servers/frameworks built with friendly URLs in mind?

I'm interested as well in when rewriting to friendly URLs became common, and when serving friendly URLs natively became common

Answer 1

I’d say the first publicly available website of the Web had/has a friendly URL:

http://info.cern.ch/hypertext/WWW/TheProject.html

The same is true for many of the early websites, e.g. the WWWVL (see the history, which contains some of the original URLs).

It’s a subject for debate if the file extension (.html) is "friendly" or not. I’d say especially in the first years it was important for users. But even today it can be good for usability, e.g. if you provide the resource in several different file formats.

But to be fair, those sites don’t use many GET forms, if any at all (at least in 1995 the form element was defined, which can be considered "HTML 2"). You can get friendly URLs by using static HTML files "for free", but if you provide GET forms, you’d have to rewrite the URLs.

Answer 2

When exactly did people start making web technologies handling this though?

mod_rewrite handles this functionality on Apache and mod_rewrite has been available since Apache 1.3, which was released on June 6, 1998.

See also:
http://en.wikipedia.org/wiki/Rewrite_engine

Answer 3

I would probably go with this link which puts the idea being put to an acronym at 2000.

http://en.wikipedia.org/wiki/Restful

I can only offer anecdotal on your last concern. I don't recall being particularly aware of Restful vs. Soap until shortly after I became UI web developer in 2005ish but definitely had the sense it was still something a lot of people didn't think about.

Answer 4

We actually have Google to thank for this.

Google was founded in 1998, but in 1999 they released PageRank which was a popular tool for checking the ranking of a site in Google's index. PageRank was this ambiguous number that represented the score of a URL compared to other URLs in Google's database.

When PageRank was released Google gave limited information on how their page ranking algorithm worked, but one thing they did state was that words in the URL were included in ranking.

Now when you search for content using Google. It will also highlight search terms in the URL as part of the results highlighting.

Thus was born human readable URLs. Everyone wanted to get a better ranking so all these cryptic query parameters were replaced with keywords.

We call them human readable but they are really web crawler readable.

Answer 5

The first REST model began with Rob Fielding's PhD thesis in 2000. The technology behind rewriting URLs existed from the start -- in fact, you could say that every traditional web server is a RESTFul application offering file system abstraction.

But what you're probably asking about is popularity -- when did REST become popular for use cases other than browsing file systems?

Let's instead talk about WHY REST became popular. I feel the answer really comes down to competing frictions.

First of all: let's take the term "friendly urls." Engineers have always used urls that are optimized for the type of development that is popular at the time. In your example, blog.php?action=edit&id=1234 is very friendly -- if you're working in a single editor on a single file, hosted by an engine that converts a file system to an application server. You know that there will be a file called blog.php and that it will house the code that will handle the edit action. It didn't matter that the URL wasn't friendly to users, as they were expected to use the rendered content to traverse the application, not the URL.

When the web was born, server hardware was expensive and most web applications were very small relative to the server's capacity. A server would generally be set up to serve any content it found in a directory (with rules to execute scripts with known extensions), relative to a URL. So you might have http://example.com/ serving content stored in /var/opt/wwwroot/example. As a developer, you'd be given a directory to work in; if you wanted to add some functionality to your program, you'd build, buy or download a script and stick it in a directory (knowing it would be served relative to that directory. Integration involved marking up the script to look how you want.

The following factors contributed to change the definition of "friendly" from "friendly for a debugging scripts" to "friendly for integrators:"

• Servers got a lot less expensive; applications got more complicated. Rather than one server running many applications, it became common to run a single application across many servers.
• Most developers could run their own dedicated servers, rather than sharing with other orgs/teams; suddenly the linkage between URL and location on disk became a lot less important for debugging.
• Companies started to offer developers self-service, hosted versions of applications that used to be sold as scripts to be served (SaaS). Suddenly, integration required OTHER PEOPLE looking at your URLs, people who didn't care that your application was written in PHP but did care that the URLs required a lot of unrelated noise.
• The "business tiers" of applications shifted from proprietary binary protocols to HTTP; this was consider valuable for network securitization and simplification. Suddenly "backend" developers needed a way to integrate with their peers via URLs. This involved some missteps (like SOAP), URLs that weren't about file locations but were still more about the backend systems' details than the integrators' details.
• Engineers feeling the pain of hard to integrate APIs, both internal and external, discovered the REST model and it seemed legit. But they were using web frameworks optimized for URLs where most information was transferred via headers, url parameters and form posts. To switch to a REST model meant complicated rewrite rules and homebrewed URL parsing.
• Around 2007, enter Sinatra and others -- web frameworks that exploited the inexpensive server hardware to build a web server intended for a single application, one that integrated code and URL routing into a single abstraction and made extracting parameters from a URL a first order concern. Because these frameworks weren't designed to build MVC HTML apps intended for browsers, they had fewer moving parts. Building a web service regardless of URL is lower friction.

All these factors -- reduction in server cost, ownership of servers by developers, http as the transport for integration, an urgency for simplified integration and new frameworks that made integrating via REST easier than serving a web page -- slowly evolved RESTful integration from a PhD thesis to the foremost integration style for both the public web and enterprise development.