Enterprise internal URL conventions

Never rely on whether your app will be internal or external. Always develop as though the audience of the app will be outside your control (because it is).

Go with ENV.APPNAME.DOMAIN.TLD

With www. as the alias for "production".

If you are deploying internal only, you have great freedom in selection. However with the Top Level Domains opening up as they have recently, you do want to take some care to not conflict with an upcoming new external name.

eg, you could deploy as http://contact.app/ but if the .app TLD gets registered then you could find yourself conflicting.

So you are probably best using something like http://contact.local/ or http://contact.lan/

For reasons of Apple and their Bonjour service compatibility you are best to avoid .local so perhaps go with .lan

Alternatively just http://contact.ourcompany/ would work pretty good if your company name is highly unlikely to ever become a TLD.

I would avoid the app name as a subdirectory because it is unnecessary and just makes it longer. Virtual hosting is the way to go there with a unique URL per app.

And you are quite correct in avoiding server names, that is a definite no-no because servers come and go.

Edit 1: See RFC2606 and take your pick from the available internal use TLD's referenced there.

Just as a note to the comments - .local and .lan as I recommend are not registerable as per the above RFC. You could use .priv and .test as well for the same reasons.

This somehwat opinion based because when you only deploy your application internally you have full control and than it really doesn't matter what you do...

Most users will bookmark what internal web applications they need to use anyway, so don't fret too much about their URL's.

As the sysadmin I would love more applications that give me the choice to deploy either in a configurable subdirectory or the root on a subdomain, allowing the choice of using subdomains or not.

It takes a more considerate developer not to go the "easy" route and just include a hardcoded (relative) reference "href=/images/bullet.png" on a random page and instead of building a reference from a number of deployment/configuration settings "href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Please make your deployment choices such as any hostnames, port numbers, choices in HTTP/HTTPS configuration settings and do not hardcode them.

I have often been on the receiving end "management wants all internal apps under http://intranet/apps/ because appname.intranet is soo confusing. And the opposite from our vendors; we need appname.intranet for our appliance/application as we have built-in check against iframes, inlining man-in-the-middle-attacks and reverse proxying....

I've found that a lot of commercial web applications expect to be deployed in the root of the webserver and don't work too reliably when deployed in some random subdirectory. I.e. they include, for instance, more or less hard-coded paths to /css/main.css sub-directories, making it difficult to host multiple applications on the same host. But those lot do not appear overly worried about the portability of their code either.