Convenciones de URL internas de empresa

desarrollador aquí ... Me gustaría su perspectiva de TI sobre este ...

Estoy creando una nueva aplicación web interna para mi empresa y estoy empezando a pensar en cómo se implementará. Muchas de las aplicaciones web existentes aquí están vinculadas al uso de los nombres de sus servidores directamente, como este:

http://webserver123/someInternalApp/

Esto me hace sentir incómodo por una variedad de razones. Los nombres de los servidores cambian, los servidores caen y los usuarios no deberían tener que conocer los nombres de los servidores para encontrar su aplicación web. El uso de nombres de servidores nos impide intercambiar servidores o agregar equilibradores de carga. Si puede pensar en otras razones por las que esto es malo, avíseme para que pueda defender mejor esta práctica.

En el futuro, me gustaría tener algunos mejores nombres de dominio configurados en nuestro DNS interno que apunten al servidor web y la aplicación apropiados. En mi último trabajo, seguimos una convención algo como esto:

• Para la producción: http://someInternalApp.myCompany.com/
• Para prueba: http://test.someInternalApp.myCompany.com/
• Para desarrollo: http://dev.someInternalApp.myCompany.com/

Esto me gusta más , ya que el nombre de la aplicación es una parte clave del nombre de dominio y la designación del entorno de desarrollo / prueba / producción es simple. Sin embargo, tengo algunas reservas:

• Poner el nombre de la aplicación en el subdominio eventualmente creará muchos subdominios largos y únicos. Me gusta tener diferentes dominios para cada aplicación, pero también siento que podría ser difícil de administrar.
• Aparte del nombre de la aplicación, no hay nada que indique que esta URL es solo interna. He leído sobre otras organizaciones que usan un subdominio como "corp.myCompany.com" o "int.myCompany.com" que podría ser bueno. No quiero que los usuarios tengan la impresión de que pueden acceder a estos desde casa.

Aquí hay algunas opciones sobre a qué me estoy inclinando para los nombres de dominio internos:

Nombre de la aplicación en el subdominio interno: (se alargan un poco, pero creo que todo está bien empaquetado)

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

Nombre de la aplicación como subdirectorio: (nombre de dominio más corto, pero implica que todas las aplicaciones son parte de un sitio unificado, lo que puede no ser, y desconecta la designación del entorno de la aplicación)

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

Entonces, discutamos ... ¿Qué piensas sobre estas opciones? ¿Hay algo mejor o más común que me haya perdido? Tengo la oportunidad de poner a mi empresa en un mejor camino en este sentido, por lo que me gustaría encontrar una buena convención para recomendar.

¡Gracias!

Nunca confíes en si tu aplicación será interna o externa. Siempre desarrolle como si la audiencia de la aplicación estuviera fuera de su control (porque lo es).

Vaya con ENV.APPNAME.DOMAIN.TLD

Con www. como el alias de "producción".

Si está implementando solo internamente, tiene una gran libertad de selección. Sin embargo, con los dominios de nivel superior que se abren como lo han hecho recientemente, debe tener cuidado de no entrar en conflicto con un nuevo nombre externo.

por ejemplo, podría implementar como http://contact.app/ pero si se registra el TLD .app, entonces podría encontrarse en conflicto.

Entonces, probablemente sea mejor usar algo como http: //contact.local/ o http: //contact.lan/

Por razones de Apple y su compatibilidad con el servicio Bonjour, es mejor evitar .local, así que quizás vaya con .lan

Alternativamente, solo http: //contact.ourcompany/ funcionaría bastante bien si es poco probable que el nombre de su empresa se convierta en un TLD.

Evitaría el nombre de la aplicación como subdirectorio porque es innecesario y solo lo hace más largo. El alojamiento virtual es el camino a seguir con una URL única por aplicación.

Y tiene bastante razón al evitar los nombres de los servidores, eso es definitivamente un no-no porque los servidores van y vienen.

Edición 1 : consulte RFC2606 y elija entre los TLD de uso interno disponibles a los que se hace referencia allí.

Solo como una nota a los comentarios: .local y .lan como recomiendo no se pueden registrar según el RFC anterior. Podrías usar .priv y .test también por las mismas razones.

Esta opinión está basada en que, cuando solo implementa su aplicación internamente, tiene el control total y realmente no importa lo que haga ...

La mayoría de los usuarios marcarán qué aplicaciones web internas necesitan usar de todos modos, así que no se preocupe demasiado por sus URL.

Como administrador del sistema, me encantaría tener más aplicaciones que me dan la opción de implementarlo en un subdirectorio configurable o en la raíz de un subdominio, lo que me permite elegir usar subdominios o no.

Se necesita un desarrollador más considerado para no seguir la ruta "fácil" e incluir una referencia "relativa" ( href=/images/bullet.png"relativa") en una página aleatoria y en lugar de crear una referencia a partir de una serie de configuraciones de implementación / configuración " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Realice sus elecciones de implementación, como nombres de host, números de puerto, opciones en las configuraciones de configuración HTTP / HTTPS y no las codifique.

A menudo he estado en el extremo receptor "la administración quiere todas las aplicaciones internas http://intranet/apps/porque appname.intranetes muy confusa. Y lo contrario de nuestros proveedores; necesitamos appname.intranetnuestro dispositivo / aplicación ya que tenemos una verificación integrada contra iframes, que incluye a man-in-the -medios ataques y proxy inverso ...

Descubrí que muchas aplicaciones web comerciales esperan implementarse en la raíz del servidor web y no funcionan de manera muy confiable cuando se implementan en algún subdirectorio aleatorio. Es decir, incluyen, por ejemplo, rutas más o menos codificadas a /css/main.csssubdirectorios, lo que dificulta el alojamiento de múltiples aplicaciones en el mismo host. Pero esos lotes tampoco parecen estar demasiado preocupados por la portabilidad de su código.