What are the pros for using extension-less URLs?

The reason for extension-less URLs is that it is technology independent. If you want to change how your content is rendered you do not have to change the URL.

W3: Cool URIs don't change

File name extension

This is a very common one. "cgi", even ".html" is something which will change. You may not be using HTML for that page in 20 years time, but you might want today's links to it to still be valid. The canonical way of making links to the W3C site doesn't use the extension....

Conclusion

Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds. However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. Often, this is because they are using tools whose task is seen as to present the best site in the moment, and no one has evaluated what will happen to the links when things change. The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.

It's mostly done for aesthetic purposes.

There is a very minor potential security benefit (a user doesn't immediately know what language the backend code is written in) but this is negligible.

A related blog post.

People claim it makes for better SEO, even if I am not personally convinced of that. Many clients request these extension-less URLs nowadays, so it's just as well that it can be easily achieved.

If you are running IIS 7, you can switch the AppPool to run on the Integrated Pipeline, thereby removing the need to have specific extensions mapped to the ASP.NET engine. Once that is done, you can instruct Sitecore to use extension-less urls in the web.config setting (assuming Sitecore 6):

<linkManager defaultProvider="sitecore">
  <providers>
    <clear />
    <add name="sitecore" type="Sitecore.Links.LinkProvider, Sitecore.Kernel" 
         addAspxExtension="false"    /* This one is set to true, per default */
         alwaysIncludeServerUrl="false" 
         encodeNames="true" 
         languageEmbedding="asNeeded" 
         languageLocation="filePath" 
         shortenUrls="true" 
         useDisplayName="false" />
  </providers>
</linkManager>

And you're set.

Be aware that early versions of Sitecore 6 had a few issues when running Integrated Pipeline. More information can be found here.

As stated, one of the advantages is that you do not tie URLS to a specific technology or language. Also, one of the advantages is that it allows you to manage the output format from within the application if you wish to do so.

But this is relevant only within a "routed" code framework, where you would basically attach url routes to code.

For instance, in my code library, you can specify the allowed output format of an url by

1) Setting an Accept header in the HTTP header 2) Attaching a valid extension to the URL

So the code for /my/simple/url.html, /my/simple/url.xml and /my/simple/url.json is exactly the same. The ouput manager will be responsible for outputing the content in the proper way.

So if you change the underlying technology, you are still able to keep the same URL pattern within the new version of you application.

From there, since you are parsing the URL withing your own code to extract the data, it generally gives you the opportunity to make SEO-friendly URL, i.e. more meaningful URLs in terms of search engine indexing. You can then define more meaningful URL patterns within you web application structure.

Only thing I can think of is to make it easier for the end user to remember/type, other than that I don't see any reason, I also ran this by our admin and he says some say SEO but if he was to use it, he would use it for a level if security.

Because user does not need to know technology behind a page. Example: domain.com/Programs/Notepad