Convenções de URL interno da empresa

desenvolvedor aqui ... Eu gostaria da sua perspectiva de TI neste ...

Estou criando um novo aplicativo 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 ao uso direto de seus nomes de servidor, assim:

http://webserver123/someInternalApp/

Isso me deixa desconfortável por vários motivos. Os nomes dos servidores são alterados, os servidores ficam inativos e os usuários não precisam saber os nomes dos servidores para encontrar seu aplicativo Web. O uso de nomes de servidor nos impede de trocar servidores ou adicionar balanceadores de carga. Se você puder pensar em outras razões pelas quais isso é ruim, informe-me para que eu possa defender melhor a mudança dessa prática.

No futuro, gostaria de ter alguns nomes de domínio melhores configurados em nosso DNS interno que apontem para o servidor e aplicativo da web apropriados. No meu último trabalho, seguimos uma convenção mais ou menos assim:

• Para produção: http://someInternalApp.myCompany.com/
• Para teste: http://test.someInternalApp.myCompany.com/
• Para desenvolvimento: http://dev.someInternalApp.myCompany.com/

Eu gosto mais disso , pois o nome do aplicativo é uma parte essencial do nome do domínio e a designação do ambiente dev / test / prod é simples. No entanto, tenho algumas reservas:

• A colocação do nome do aplicativo no subdomínio acabará por criar muitos subdomínios longos e exclusivos. Gosto de ter domínios diferentes para cada aplicativo, mas também acho que pode ser difícil de gerenciar.
• Além do nome do aplicativo, não há nada para designar que esse URL é apenas interno. Eu li sobre outras organizações usando um subdomínio como "corp.myCompany.com" ou "int.myCompany.com", o que pode ser bom. Não quero que os usuários tenham a impressão de que podem acessá-los em casa.

Aqui estão algumas opções sobre o que eu estou inclinado para nomes de domínio interno:

Nome do aplicativo no subdomínio interno: (eles ficam um pouco longos, mas tudo está bem embalado, acho)

• http://someInternalApp.corp.myCompany.com/
• http://dev.someInternalApp.corp.myCompany.com/

Nome do aplicativo como subdiretório: (nome de domínio mais curto, mas implica que todos os aplicativos fazem parte de um site unificado, o que pode não ser, e desconecta a designação do 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? Existe algo melhor ou mais comum que eu possa ter perdido? Tenho a oportunidade de colocar minha empresa em um caminho melhor nesse sentido, por isso gostaria de encontrar uma boa convenção para recomendar.

Obrigado!

Nunca dependa se seu aplicativo será interno ou externo. Sempre desenvolva como se o público do aplicativo estivesse fora do seu controle (porque está).

Vá com ENV.APPNAME.DOMAIN.TLD

Com www. como o alias para "produção".

Se você estiver implantando apenas interno, terá grande liberdade na seleção. No entanto, com a abertura dos domínios de nível superior, como recentemente, convém tomar cuidado para não entrar em conflito com um novo nome externo.

por exemplo, você pode implantar como http://contact.app/, mas se o TLD .app for registrado, poderá ser conflitante.

Portanto, provavelmente é melhor usar algo como http: //contact.local/ ou http: //contact.lan/

Por motivos de compatibilidade com a Apple e o serviço Bonjour, é melhor evitar o .local; talvez seja esse o caso

Como alternativa, apenas http: //contact.ourcompany/ funcionaria muito bem se o nome da sua empresa dificilmente se tornasse um TLD.

Eu evitaria o nome do aplicativo como um subdiretório, porque é desnecessário e apenas o torna mais longo. Hospedagem virtual é o caminho a percorrer com um URL exclusivo por aplicativo.

E você está certo em evitar nomes de servidores, isso é definitivamente não-não, porque os servidores vêm e vão.

Edit 1 : Veja RFC2606 e faça a sua escolha nos TLDs de uso interno disponíveis aqui mencionados.

Apenas como uma observação aos comentários - .local e .lan, como eu recomendo, não são registráveis ​​conforme a RFC acima. Você também pode usar .priv e .test pelos mesmos motivos.

Essa opinião é baseada em alguma coisa, porque quando você implanta apenas seu aplicativo internamente, você tem controle total e isso realmente não importa o que você faz ...

A maioria dos usuários marcará quais aplicativos da Web internos eles precisam usar de qualquer maneira, portanto, não se preocupe muito com os URLs.

Como administrador do sistema, eu adoraria mais aplicativos que me dêem a opção de 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 um desenvolvedor mais atencioso para não seguir a rota "fácil" e incluir apenas uma referência "relativa" ( href=/images/bullet.png"relativa") em uma página aleatória e em vez de criar uma referência a partir de várias definições de implantação / configuração " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Faça suas escolhas de implantação, como nomes de host, números de portas, opções nas configurações de HTTP / HTTPS e não as codifique.

Muitas vezes estive do lado de quem recebe "o gerenciamento quer todos os aplicativos internos http://intranet/apps/porque appname.intraneté muito confuso. E o oposto de nossos fornecedores; precisamos appname.intranetdo nosso dispositivo / aplicativo, pois temos verificação interna contra iframes, destacando o homem-em-um -ataques médios e proxy reverso ....

Descobri que muitos aplicativos Web comerciais esperam ser implantados na raiz do servidor da Web e não funcionam de maneira confiável quando implantados em algum subdiretório aleatório. Ou seja, incluem, por exemplo, caminhos mais ou menos codificados para /css/main.csssubdiretórios, dificultando a hospedagem de vários aplicativos no mesmo host. Mas esses grupos também não parecem muito preocupados com a portabilidade de seu código.