Question 2.6. URL Rewriting

[viktor-yakubiv]

Навести приклади веб сайтів чи веб сервісів, що використовують незвичну схему передачі GET параметрів. На слайді 35 розглядались три більш-менш розповсюджені схеми:

1. в query string: https://host.co/item?id=123
2. в path: https://host.co/item/123
3. в hash string (fragment): https://host.co/item#123 або https://host.co/item#id=123

Можна наводити приклади інших схем, що відрізняються від цих трьох. Також можна наводити не конкретні сайти, а веб фреймворки, що використовують якусь іншу схему передачі параметрів.

[viktor-yakubiv]

Якщо говорити про фреймворки, більшіть реалізованих на сьогоднішній день уже мають реалізовну систему роутингу. Наприклад:

• Play Framework (Java, Scala) – файли конфігуріції в файлах *routes в форматі <method> <route> <controller method>. Детальніше в документації

• Rails (Ruby) – файл конфігурації conf/routes.rb в форматі подібному до попереднього фреймворка. Детальніше в документації

• Django (Python) – файли конфігурації у вигляді звичайних списків, де кожен елемент є викликом стандартної функції-конструктора url; здебільшого файл знаходиться за адресою <app-name>/urls.py. Детальніше в документації

Якщо йдеться про singlepage application (SPA), роутинг робиться на стороні клієнта. Найбільш популярні на сьогоднішній день фреймворки мають свої системи, які працюють на History API:

• Angular: вбудований варінт
• React: react-router
• Vue:
  • для більшості випадків рекомендується vue-router
  • для простих додатків – простий варінт «на коліні»
  • для любителів чогось «свого»: Page.js та приклад до неї

Для застосунків на чистому JavaScript можна використати одну з поулярних реалізацій, наприклад Router 5.

На стороні сервера в такому разі може бути що-завгодно, але як правило, робиться аналогічний роутинг на API.

---

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

Очевидно, таким підходом користуються переважна більшісь сучасних веб-застосунків: Їх не злічити. Google, Medium, GitHub, та навіть дрібні сьогоднішні веб-сайти.

[viktor-yakubiv]

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

Та коли не було History API, десь так до року 2011, не було можливості нормально змінити window.location без перезавантаження сторінки; а вже ось-ось 5 років була реалізована технологія AJAX і всім тах хотілося приросту швидкості та всього модного й молодіжного. Як відомо URL Hash – посилання на поточну сторінку, і на нього можна перейти без перезавантаження. Тому цей спосіб (загаданий у питанні під номером 3) й став костилем на шляху до SPA: всі URL-адреси в той час перетворилися на http://example.com/#/my/awesome/route/123, де з сервера, очевидно, завжди завантажувалася індексна сторінка з нашим JavaScript-застосунком, який вже обробляв частину після #.

Звісно, більшість таких сайтів уже вмерли, а найбільш популярні оновилися разом із ростом технологій. В часи цього підходу були тільки AngualarJS (той, що 1.6) та jQuery, які з впевненістю відходять в минуле. Та рекомендації ще можна знайти на StackOverflow.

А в ще більш древні часи, коли не було mod_rewrite, або там, де його не було (не всі хостинги підтримували), єдиним способом реалізовувати роутинг на динамічних веб-сайтах – мапити все в GET-параметри (варіант №1 з тексту питання). Древні маленькі CMS, які так працювали, зараз уже позбавилися цього, адже навіть Apache відходить в минуле. Та WordPress й інші популярні CMS все ще підтримують таки спосіб форматування URL, хоч й не використовують його за промовчанням.

[viktor-yakubiv]

З незгаданих хіба комбінований варіант.

Наприклад другого й третього у форматі: http://example.com/some/page/#comment-2014. Таке можна знайти на сайтах, де використовується CMS із зовнішньою системою для коментування, наприклад, Disquss: сайт віддає статтю, а коментарі завантажуються за допомогою JavaScript, й перехід до коментаря відбувається вже після завантаження.

Також не згадано модний сьогодні спосіб робити піддомени:

• для деяких частин застосунку, наприклад, панелі керування та основного контенту
• для кінцевих користувачів, наприклад, povarenok.ru
• для груп (організацій, проміжних користувачів), наприклад, Slack

[hoherchak]

Доволі часто помічаю на сайтах схему передачі GET-параметрів, що передбачає вміщення всіх параметрів у назву псевдо-файлу html з певними розділювачами: https://www.glassdoor.com/Job/berlin-jobs-SRCH_IL.0,6_IC2622109_IP25.htm (тут наприклад останнє число 25 - номер сторінки результатів пошуку); http://www.wg-gesucht.de/wg-zimmer-in-Berlin.8.0.1.0.html (тут наприклад останнє число 0 - номер сторінки результатів пошуку).