Чи слід використовувати регістр заголовка в URL-адресах?

Наразі ми приймаємо рішення про послідовну конвенцію про іменування на сайті з кількома веб-додатками. Історично я був прихильником "малих літер!" під час створення URL-адрес:

http://example.com/mysystem/account/view/1551

Однак протягом останнього року чи двох, особливо з моменту початку використання ASP.NET MVC та більше розгляду з URL-адресами на основі REST, я став фанатом використання великих літер кожного розділу / слова в межах URL-адреси, як це робиться. легше читати (імхо).

http://example.com/MySystem/Account/View/1551

Ми не знаходимось у ситуації, коли людям потрібно читати чи вміти розуміти URL-адреси, тому це не є драйвером. Головне, за чим ми дотримуємося, - це послідовний підхід, який є раціональним і має сенс.

Чи існують якісь стандарти, які заявляють, що добре робити так чи інакше, або питання, які ми можемо зіткнутися з (принаймні реально сучасними) налаштуваннями, які б обрали перевагу над іншою? Який загальний консенсус для цієї дискусії зараз?

Оскільки вибір переважно косметичний (тобто більшість систем не розмежовує верхній і нижній регістри, а користувачі, звичайно, ні), то я б запропонував просто піти з тим, що робить вас щасливими. Послідовність у програмі є ключовим , а не обраним вами способом.

Оскільки ви використовуєте ASP.Net, я б рекомендував перейти з підходом PascalCase - оскільки саме це має тенденцію існувати в рамках Microsoft (системні бібліотеки тощо).

Більшість веб-переглядачів роблять досить хорошу роботу, приховуючи URL-адресу від користувача, до такої міри, що дуже багато людей, у яких Google є домашньою сторінкою, потім шукатимуть фейсбук та натискатимуть його, а не вводять URL-адресу facebook у свою браузер.

Для внутрішніх веб-сайтів це не так важливо, поки ви відповідаєте цьому.

Для зовнішніх, публічних сайтів, ви, мабуть, хочете дотримуватися нижнього регістру, що є більш-менш стандартним для веб-хостингу Linux / Apache. Наскільки я пам’ятаю, деякі версії Firefox також здаються, що обробляють обкладинки URL інакше, ніж IE. Це може стосуватися і Chrome.

Послідовний корпус також має значення для оптимізації пошукових систем. Ви не хочете, щоб Google бачив нижній регістр.aspx та нижній регістр.aspx різними сторінками з подвійним вмістом. Хоча їхні алгоритми намагаються запобігти цій помилковій ідентичності, це час від часу відбувається і може призвести до покарання сторінки.

Поки користувачі можуть вводити його як завгодно, це насправді не має значення. Особисто я віддаю перевагу TitleCase, але є багато тих, хто не погоджується. Якщо ви послідовні, ніхто не буде проти.

Якщо ваш веб-сервер з якихось причин не може показати мені, http://foo.com/HelloWorldколи я намагаюся перейти http://foo.com/helloworld, слід вибрати для великих літер. У той час, як люди рідко вводять повні URL-адреси в ці дні, адреси, спрямовані на лицьові сторони, повинні бути доступними, без того, щоб поспішати з великими літерами.

Те, що ви почали використовувати MVC, не повинно "просочуватися" у вашу REST абстракцію. Є вагомі причини використовувати всі малі URL-адреси з тире між словами. URI (не доменні імена) ВАЖЛИВІ до регістру. Якщо ви все обмежите і використовуєте тире для розділення слів, ви усунули багато роботи з здогадами та одноразовими, і якщо ви використовуєте проксі-сервер (nginx, nodejs, apache ...), у вас не буде все починати ламатися адже це раптом чутливість до регістру.

"MiXeD-CaSe NaMeS. Не плутайте своїх користувачів за допомогою" Змішування в верхньому регістрі "і" Малі символи "в URL-адресі. Дотримуйтесь малі літери і не змушуйте їх вгадувати. Якщо ваш користувач насправді вводить URL у змішаному регістрі, нормалізує його на сервері та обслуговує відповідний регістр ".

У той час як домени верхнього рівня не чутливі до регістру і шляхи Windows , використовувати комбінацію капіталу і Паскаль випадку, наші програми чутливі до вступників шляхах запиту, де шляху або компоненти в них, як правило , нормованих на стандартному випадку, так /format/JSON/і /format/json/є запити на два різні формати та посилання на два різних ресурси.

Кожного разу, коли я бачив http://www.somewebsite.com/Having/URLs/That-Look-Something-Like-This/ , я відчував, що намір розробника полягав у тому, щоб виглядати дещо іншим, ніж решта, але це нічого новаторство і при цьому це не допоможе поліпшити читаність, особливо тепер, коли у вас є я і л , Про і 0 , інші літери змагаються для аналізу.

Я не знаю жодного консенсусу, і не вірю, що його має бути, оскільки щось таке просте, як використання великих літер лише певних частин URL-адреси, може мати позитивний вплив на читабельність, і я впевнений, що хтось десь уже з'являється з цікавими ідеями, коли справа стосується застосування справ у форматі листів до URL-адрес.

Але, судячи з того, що більшість веб-серверів працює на Linux і що ми, розробники, завжди закінчуємо стандартизацією вхідних текстових даних, оскільки вхідні дані відрізняються від регістру, я дотримуюся того, як це робилося весь час.

НІКОЛИ не використовуйте заголовок з причини зручності використання! Уявіть, скільки часу вам слід витратити та натиснути на виконання URL-адреси різних випадків у вашому телефоні MOBILE !