Nunca confie se seu aplicativo será interno ou externo. Sempre desenvolva como se o público do aplicativo estivesse fora de seu controle (porque é).
Vá com ENV.APPNAME.DOMAIN.TLD
Com www. como o alias para "produção".
desenvolvedor aqui ... Gostaria da sua perspectiva de TI sobre esse ...
Estou criando um novo aplicativo da web interno para minha empresa e começando a pensar em como ele será implantado. Muitos dos aplicativos da web existentes aqui estão vinculados usando seus nomes de servidores diretamente, como este:
http://webserver123/someInternalApp/
Isso me deixa desconfortável por vários motivos. Os nomes dos servidores mudam, os servidores ficam inativos e os usuários não precisam saber nomes de servidores para encontrar seus aplicativos da web. Usar nomes de servidores nos impede de trocar servidores ou adicionar balanceadores de carga. Se você puder pensar em outras razões, isso é ruim, avise-me para que eu possa defender melhor essa prática.
De agora em diante, gostaria de ter alguns nomes de domínio melhores configurados em nosso DNS interno que apontarão para o servidor da Web e & aplicativo. No meu último trabalho, seguimos uma convenção algo assim:
http://someInternalApp.myCompany.com/
http://test.someInternalApp.myCompany.com/
http://dev.someInternalApp.myCompany.com/
Eu gosto disso melhor , já que o nome do aplicativo é uma parte importante do nome de domínio, e a designação do ambiente dev / test / prod é simples. No entanto, tenho algumas reservas:
Aqui estão algumas opções sobre o que eu estou inclinando para nomes de domínio internos:
Nome do aplicativo no subdomínio interno: (eles ficam um pouco longos, mas tudo está bem junto, acho)
http://someInternalApp.corp.myCompany.com/ http://dev.someInternalApp.corp.myCompany.com/ Nome do aplicativo como um subdiretório: (nome de domínio mais curto, mas implica que todos os aplicativos fazem parte de um site unificado, o que eles podem não ser, e desconecta a designação de ambiente do aplicativo)
http://corp.myCompany.com/someInternalApp http://dev.corp.myCompany.com/someInternalApp Então, vamos discutir ... O que você acha dessas opções? Há algo melhor ou mais comum que eu possa ter perdido? Eu tenho a oportunidade de colocar minha empresa em um caminho melhor nesse sentido, então eu gostaria de encontrar uma boa convenção para recomendar.
Obrigado!
Se você estiver implantando apenas internamente, terá grande liberdade na seleção. No entanto, com a abertura dos domínios de primeiro nível, como acontece recentemente, você deve tomar cuidado para não entrar em conflito com um novo nome externo.
Por exemplo, você pode implantar como link , mas se o TLD .app for registrado, você poderá se encontrar em conflito.
Então é melhor você usar algo como link ou link
Por razões da Apple e sua compatibilidade com o serviço Bonjour, é melhor evitar o .local, então talvez vá com .lan
Alternativamente, apenas o link funcionaria muito bem se o nome de sua empresa fosse altamente improvável de se tornar um TLD.
Eu evitaria o nome do aplicativo como um subdiretório porque é desnecessário e apenas aumenta o tempo. A hospedagem virtual é o caminho a percorrer com um URL exclusivo por aplicativo.
E você está bem correto em evitar nomes de servidores, isso é um não-definitivo porque os servidores vêm e vão.
Editar 1 : consulte RFC2606 e faça a sua escolha a partir do uso interno disponível TLDs referenciados lá.
Assim como uma nota para os comentários - .local e .lan como eu recomendo, não podem ser registrados conforme o RFC acima. Você poderia usar .priv e .test também pelas mesmas razões.
Esta opinião de algum tipo baseia-se porque quando você só implementa seu aplicativo internamente, você tem controle total e, realmente, não importa o que você faz ...
A maioria dos usuários indicará quais aplicativos da web internos eles precisam usar de qualquer maneira, portanto não se preocupe muito com os URLs deles.
Como o sysadmin, eu adoraria mais aplicativos que me permitissem implantar em um subdiretório configurável ou na raiz de um subdomínio, permitindo a opção de usar subdomínios ou não.
É preciso que um desenvolvedor mais atencioso não use a rota "fácil" e inclua apenas uma referência (%) relativa (codificada) " href=/images/bullet.png " em uma página aleatória e em vez de criar uma referência a partir de várias configurações de implantação href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png "
Favor fazer suas opções de implantação, como nomes de host, números de porta, opções nas configurações HTTP / HTTPS e não codificá-las.
Eu sempre fui o destinatário "O gerenciamento quer todos os aplicativos internos em http://intranet/apps/ porque appname.intranet é muito confuso. E o oposto de nossos fornecedores, precisamos de appname.intranet para nosso appliance / aplicativo, conforme construímos -para checar contra iframes, embutir ataques man-in-the-middle e reverter proxies ....
Descobri que muitos aplicativos comerciais da web esperam ser implementados na raiz do servidor da web e não funcionam de maneira confiável quando implementados em algum subdiretório aleatório. Ou seja Eles incluem, por exemplo, caminhos mais ou menos codificados para os subdiretórios /css/main.css , dificultando o armazenamento de vários aplicativos no mesmo host. Mas esse lote também não parece muito preocupado com a portabilidade de seu código.