Zarządzanie przestrzenią adresów URL aplikacji internetowej

Adresy URL

Jak powinny wyglądać adresy URL aplikacji internetowej? Czy mają odzwierciedlać strukturę bazy danych? A może strukturę informacji serwisu WWW? Kto za nie odpowiada: projektant szablonu HTML, programista czy osoba odpowiedzialna za bazę danych? Jak uchronić się przed dezaktualizacją adresów w przypadku przebudowy witryny?

Istota problemu przestrzeni adresowej w aplikacji internetowej wynika stąd, że adresy URL są widoczne z zewnątrz. Posługują się nimi internauci dodając linki zwrotne oraz wyszukiwarka. Możemy wymienić silnik aplikacji, strukturę bazy danych czy nawet stosowaną platformę sprzętowo-programową (z systemem operacyjnym i językiem programowania włącznie). Zmiany te nie są widoczne na zewnątrz aplikacji. Wszystkie linki prowadzące do serwisu pozostaną poprawne, pozycja w wyszukiwarce nie zmieni się. Jeśli jednak wymienimy adresy URL, to wieloletni wysiłek włożony w pozycjonowanie witryny może przepaść.

Adresy URL należy uwzględnić w aplikacji już we wczesnych fazach projektu, tak by stały się one integralną częścią, a nie doklejonym dodatkiem. Należy zwrócić uwagę na to, by adresy URL:

• były "ładne" i zrozumiałe,
• nie odzwierciedlały struktury bazy danych,
• nie zawierały identyfikatorów całkowitoliczbowych,
• nie wiązały aplikacji z językiem programowania.

Od strony implementacyjnej ważne jest, by umożliwić edycję adresów URL w panelu administracyjnym witryny oraz ułatwić współpracę na linii projektant szablonu - programista silnika.

Struktura adresu

Adresy: http://example.net/index.php?id=192&dz=php http://example.net/php/art/192/

zawierają liczby będące najprawdopodobniej jakimiś identyfikatorami w bazie danych (np. 110, 192, 809). Takie rozwiązanie powoduje, że już wymiana rekordu (np. usunięcie i ponowne dodanie identycznego rekordu) dezaktualizuje adres URL.

Jeśli podstrony identyfikujemy specjalnie preparowanymi napisami, a nie liczbami całkowitymi, np.:
http://example.net/index.php?art=semantyka-html http://example.net/php/art/semantyka-html.php
otrzymujemy rozwiązanie wygodniejsze. Jednak z racji na wystąpienie rozszerzenia .php. wymiana stosowanego języka (np. z PHP na Python) spowoduje zmianę adresów URL lub wymusi sztuczne stosowanie rozszerzeń .php w aplikacji napisanej w innym języku.

Rozwiązaniem najbardziej uniwersalnym są adresy stosujące rozszerzenie .html:

http://example.net/php/art/semantyka-html.html oraz adresy pozbawione rozszerzenia: http://example.net/php/art/semantyka-html

W obu przypadkach zestaw adresów dotyczących wybranego artykułu może zostać rozbudowany o kolejne podstrony:

http://example.net/php/art/semantyka-html/images.html
http://example.net/php/art/semantyka-html/page-1.html
http://example.net/php/art/semantyka-html/edytuj.html

Udostępnianie adresów URL w panelu administracyjnym

Wiedząc, jaka ma być struktura adresu, zastanówmy się, kto ma podjąć decyzję o adresie konkretnej podstrony. Dodajemy do witryny artykuł zatytułowany Programowanie obiektowe w PHP. Kto powinien nadać adres URL nowej podstrony? Jak ten adres powinien wyglądać?

Osobą odpowiedzialną za adres podstrony powinien być redaktor wprowadzający nowy artykuł do bazy danych lub administrator całego serwisu. Ustalenie adresu URL nowego artykułu musi odbywać się z poziomu panelu administracyjnego, bez ingerencji w kod aplikacji (np. pliki .php czy .htaccess).

Zatem w odpowiednim formularzu obok treści artykułu redaktor wprowadzi adres:

http://example.net/obiekty

Może jednak powinien użyć jednego z poniższych adresów:

http://example.net/artykuly/obiekty
http://example.net/art/php/obiekty
http://example.net/php/art/obiekty

A może w miejsce napisu obiekty należy użyć skróconego tytułu:

http://example.net/programowanie-obiektowe-w-php
http://example.net/artykuly/programowanie-obiektowe-w-php
http://example.net/art/php/programowanie-obiektowe-w-php
http://example.net/php/art/programowanie-obiektowe-w-php

Ta decyzja nie powinna wiązać się z modelem bazy danych ani silnikiem aplikacji. Powinna to być niezależna decyzja redaktora lub administratora, wolna od ograniczeń wynikających z kodu aplikacji.

Adres podstrony serwisu powinien być dowolnym napisem, np.:

http://example.net/c/obiekty
http://example.net/arts/super/mocne/programowanie-obiektowe-w-php
http://example.net/a/b/c/nowy-art

Jeśli adresy działów (tj. /c/, /arts/super/mocne/, /a/b/c/) oraz nazwa artykułu (np. obiekty, programowanie- obiektowe-w-php i nowy-art) są dowolnymi napisami, to artykuły będziemy mogli przenosić pomiędzy działami, bez dezaktualizacji adresów URL.