这里的开发人员…我希望你的IT观点在这个…
我正在为我的公司构build一个新的内部Web应用程序，并开始考虑如何部署它。 这里的许多现有的networking应用程序直接链接到使用他们的服务器名称，如下所示：
http://webserver123/someInternalApp/ 这使我感到不舒服的原因有很多。 服务器名称更改，服务器closures，用户不必知道服务器名称即可find其Web应用程序。 使用服务器名称阻止我们交换服务器或添加负载平衡器。 如果你能想出其他的原因，那就让我知道，这样我可以更好地改变这种做法。
outlook未来，我想在内部DNS中设置一些更好的域名，这些域名将指向相应的Web服务器和应用程序。 在我上一份工作中，我们遵循了这样一个惯例：
http://someInternalApp.myCompany.com/ : http://someInternalApp.myCompany.com/ http://test.someInternalApp.myCompany.com/ : http://test.someInternalApp.myCompany.com/ http://dev.someInternalApp.myCompany.com/ : http://dev.someInternalApp.myCompany.com/ 我更喜欢这个，因为应用程序名称是域名的关键部分，dev / test / prod环境的devise很简单。 不过，我有一些保留：
以下是我倾向于内部域名的一些选项：
内部子域中的应用程序名称:(它们有点长，但是我认为所有东西都打包在一起）
http://someInternalApp.corp.myCompany.com/ http://dev.someInternalApp.corp.myCompany.com/ 应用程序名称作为一个子目录：（较短的域名，但它意味着所有的应用程序是一个统一的网站的一部分，他们可能不是，它断开环境指定从应用程序）
http://corp.myCompany.com/someInternalApp http://dev.corp.myCompany.com/someInternalApp 那么，让我们来讨论一下…对这些select有什么看法？ 有什么更好或更常见的，我可能错过了？ 我有机会在这方面让我的公司走上一条更好的道路，所以我想找一个好的公约来推荐。
谢谢！
永远不要依靠你的应用程序是内部的还是外部的。 总是发展好像应用程序的观众将不受你的控制（因为它）。
去与ENV.APPNAME.DOMAIN.TLD
随着www。 作为“生产”的别名。
如果你只是部署内部，你有很大的自由select。 但是，随着顶级域名最近的开放，您确实需要注意不要与即将到来的新外部名称发生冲突。
例如，您可以将其部署为http://contact.app/，但如果.app TLD获得注册，则可能发现自己发生冲突。
所以你可能最好使用像http：//contact.local/或http：//contact.lan/
由于苹果和他们的Bonjour服务兼容性的原因，您最好避免使用.local，所以也可以使用.lan
或者，如果您的公司名称不太可能成为顶级域名（TLD），那么http：//contact.ourcompany/将会非常好用。
我会避免应用程序名称作为子目录，因为它是不必要的，只是使其更长。 虚拟主机是去那里与每个应用程序唯一的URL的方式。
而且你在避免服务器名称方面是非常正确的，这是一个明确的禁止，因为服务器来来去去。
编辑1 ：参见RFC2606，并从那里引用可用的内部使用TLD中挑选。
正如我build议的注释 – .local和.lan注释不能按照上面的RFC注册。 您可以使用.priv和.test以及相同的原因。
这个观点的基础是因为当你只在内部部署你的应用程序时，你有完全的控制权，而不是你做什么并不重要。
大多数用户将书签他们需要使用的内部Web应用程序，所以不要太担心他们的URL。
作为系统pipe理员，我会喜欢更多的应用程序，让我select部署在可configuration的子目录或子域的根，允许select使用子域或不。
需要一个更体贴的开发人员不要去“简单”的路线，只是在随机页面上包含硬编码（相对）参考“ href=/images/bullet.png ”，而不是从一些部署/configuration设置“ href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png ”
请进行部署select，例如任何主机名，端口号，HTTP / HTTPSconfiguration设置中的选项，并且不要对其进行硬编码。
我经常在接收端“pipe理层希望所有的内部应用程序在http://intranet/apps/因为appname.intranet太混乱了，而且与我们的供应商相反，我们需要appname.intranet作为我们的设备/应用程序。内置检查内部框架，内联中间人攻击和反向代理….
我发现许多商业Web应用程序希望部署在Web服务器的根目录下，并且在部署在一些随机的子目录中时工作不太可靠。 也就是说，它们包括或多或less硬编码的/css/main.css子目录的path，使得在同一主机上托pipe多个应用程序变得困难。 但是那些代码也不太担心代码的可移植性。