REST and the principle of encapsulation

I was playing around with my new Outlook Web Access (OWA) installation last night and it struck me that OWA appears to be a RESTful application. Good on Microsoft!

One of the main concepts in REST is the idea that all resources (in a general sense, not technical sense) in the system are uniquely addressable via a URL. It implies that the URL only contains the business end of the feature (e.g. viewing my inbox) and should have no technology association whatsoever (e.g. this feature was implemented using ASP.NET, which, by the way, OWA was).

In my simple-minded view, I think this encapsulation is very important for the following reasons.

As a (somewhat) alert software user, I couldn't care less if you implemented your software using ASP, ASP.Net, Java, Python, Perl, PHP version 4 as opposed to version 5, or what-have-you. Having a URL containing a tail of .asp, .aspx, .jsp, or .py immediately clues me into what technology you're implementing your software in, which may not be a good thing (see next paragraph). Plus, having technically specific parameters in the URL that has nothing to do with what I'm trying to do, like whether it should use UTF-8 or ISO-8859-1 encoding, is simply annoying.

As a developer, I would want to abstract the underlying implementation language away from my users for many reasons, security being one. If there's a security bug found in the current version of PHP, how do you think the hackers are going to target PHP sites? Yep, you guessed it: crawl the web searchhing for URLs with .php or .php4 extensions. Additionally, if later on, requirements change and it turns out that PHP just can't handle the scalability (sorry for the cheapshot, PHP fans), I can always pull the rug and re-implement the whole system using, oh I don't know, Ruby for instance, and do it without breaking any hyperlink that my users may have bookmarked.

Web URLs should be treated as public interfaces, and if you could change the underlying implementation without changing the interface, that would be ideal.