Konvensi URL internal perusahaan

pengembang di sini ... Saya ingin perspektif TI Anda yang satu ini ...

Saya sedang membangun aplikasi web internal baru untuk perusahaan saya, dan mulai berpikir tentang bagaimana itu akan digunakan. Banyak aplikasi web yang ada di sini terhubung ke menggunakan nama server mereka secara langsung, seperti ini:

http://webserver123/someInternalApp/

Ini membuat saya tidak nyaman karena berbagai alasan. Nama server berubah, server turun, dan pengguna tidak perlu tahu nama server untuk menemukan aplikasi web mereka. Menggunakan nama server mencegah kita dari menukar server atau menambahkan load balancers. Jika Anda dapat memikirkan alasan lain ini buruk, beri tahu saya agar saya dapat membuat alasan yang lebih baik untuk mengubah praktik ini.

Selanjutnya, saya ingin mengatur beberapa nama domain yang lebih baik di DNS internal kami yang akan mengarah kembali ke server & aplikasi web yang sesuai. Dalam pekerjaan terakhir saya, kami mengikuti konvensi sesuatu seperti ini:

• Untuk Produksi: http://someInternalApp.myCompany.com/
• Untuk Tes: http://test.someInternalApp.myCompany.com/
• Untuk Pembangunan: http://dev.someInternalApp.myCompany.com/

Saya suka ini lebih baik , karena nama aplikasi adalah bagian kunci dari nama domain, dan penunjukan lingkungan dev / test / prod sederhana. Namun, saya punya beberapa reservasi:

• Menempatkan nama aplikasi di subdomain pada akhirnya akan membuat banyak subdomain unik yang panjang. Saya suka memiliki domain yang berbeda untuk setiap aplikasi, tetapi saya juga merasa itu bisa menjadi sulit untuk dikelola.
• Selain nama aplikasi, tidak ada yang menunjukkan bahwa URL ini hanya internal. Saya telah membaca tentang organisasi lain yang menggunakan subdomain seperti "corp.myCompany.com" atau "int.myCompany.com" yang mungkin bagus. Saya tidak ingin pengguna mendapatkan kesan bahwa mereka dapat mengaksesnya dari rumah.

Berikut adalah beberapa opsi tentang apa yang saya condongkan untuk nama domain internal:

Nama aplikasi di subdomain internal: (mereka agak panjang, tapi semuanya dikemas bersama dengan baik saya pikir)

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

Nama aplikasi sebagai subdirektori: (nama domain lebih pendek, tetapi ini menyiratkan semua aplikasi adalah bagian dari satu situs yang disatukan, yang mungkin bukan, dan itu memutus penunjukan lingkungan dari aplikasi)

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

Jadi, mari kita bahas ... Apa pendapat Anda tentang opsi-opsi ini? Apakah ada sesuatu yang lebih baik atau lebih umum yang mungkin saya lewatkan? Saya memiliki kesempatan untuk mengatur perusahaan saya di jalur yang lebih baik dalam hal ini, jadi saya ingin mencari konvensi yang bagus untuk direkomendasikan.

Terima kasih!

Jangan pernah mengandalkan apakah aplikasi Anda akan internal atau eksternal. Selalu berkembang seolah-olah audiens aplikasi akan berada di luar kendali Anda (karena itu).

Pergi dengan ENV.APPNAME.DOMAIN.TLD

Dengan www. sebagai alias untuk "produksi".

Jika Anda menggunakan internal saja, Anda memiliki kebebasan besar dalam pemilihan. Namun dengan Domain Level Atas yang terbuka seperti baru-baru ini, Anda ingin berhati-hati agar tidak bertentangan dengan nama eksternal baru yang akan datang.

misalnya, Anda dapat menggunakan sebagai http://contact.app/ tetapi jika .app TLD didaftarkan maka Anda dapat menemukan diri Anda bertentangan.

Jadi Anda mungkin sebaiknya menggunakan sesuatu seperti http: //contact.local/ atau http: //contact.lan/

Untuk alasan Apple dan kompatibilitas layanan Bonjour mereka Anda sebaiknya menghindari .local jadi mungkin pergi dengan .lan

Atau hanya http: //contact.ourcompany/ akan bekerja cukup baik jika nama perusahaan Anda sangat tidak mungkin menjadi TLD.

Saya akan menghindari nama aplikasi sebagai subdirektori karena tidak perlu dan hanya membuatnya lebih lama. Hosting virtual adalah cara untuk pergi ke sana dengan URL unik per aplikasi.

Dan Anda cukup benar dalam menghindari nama server, yang pasti tidak-tidak karena server datang dan pergi.

Sunting 1 : Lihat RFC2606 dan pilihlah dari penggunaan internal TLD yang tersedia yang dirujuk di sana.

Sama seperti catatan untuk komentar -. Lokal dan .lan seperti yang saya sarankan tidak dapat didaftarkan sesuai RFC di atas. Anda dapat menggunakan .priv dan .test juga untuk alasan yang sama.

Pendapat ini didasarkan karena ketika Anda hanya menggunakan aplikasi secara internal, Anda memiliki kendali penuh dan daripada itu tidak masalah apa yang Anda lakukan ...

Sebagian besar pengguna akan mem-bookmark aplikasi web internal apa yang perlu mereka gunakan, jadi jangan terlalu khawatir tentang URL mereka.

Sebagai sysadmin saya akan menyukai lebih banyak aplikasi yang memberi saya pilihan untuk menggunakan subdirektori yang dapat dikonfigurasi atau root pada subdomain, memungkinkan pilihan menggunakan subdomain atau tidak.

Diperlukan pengembang yang lebih penuh perhatian untuk tidak menggunakan rute "mudah" dan hanya menyertakan referensi "relatif href=/images/bullet.png" yang dikodekan pada halaman acak dan bukannya membangun referensi dari sejumlah pengaturan penerapan / konfigurasi " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Silakan tentukan pilihan penyebaran Anda seperti nama host, nomor port, pilihan dalam pengaturan konfigurasi HTTP / HTTPS dan jangan hardcode mereka.

Saya sering berada di pihak penerima "manajemen menginginkan semua aplikasi internal berada di bawah http://intranet/apps/karena appname.intranetsangat membingungkan. Dan kebalikan dari vendor kami; kami memerlukan appname.intranetalat / aplikasi kami karena kami memiliki pemeriksaan bawaan terhadap iframe, inline man-in-the -middle-serangan dan membalikkan proxy ....

Saya telah menemukan bahwa banyak aplikasi web komersial berharap untuk ditempatkan di root server web dan tidak bekerja terlalu andal ketika digunakan dalam beberapa subdirektori acak. Yaitu mereka termasuk, misalnya, lebih atau kurang jalur hard-coded ke /css/main.csssub-direktori, sehingga sulit untuk meng-host beberapa aplikasi pada host yang sama. Tetapi banyak yang tidak terlalu khawatir tentang portabilitas kode mereka.