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.