Web Tima Berners‑Lee: URL, HTTP, HTML i dlaczego to ma znaczenie

Co to jest World Wide Web (a czego nie jest)

World Wide Web (często po prostu „Web”) to sposób publikowania i uzyskiwania dostępu do informacji za pomocą linków. To system, który pozwala kliknąć z jednej strony na drugą, otworzyć stronę produktu z wyniku wyszukiwania lub udostępnić link, który działa na niemal każdym komputerze czy telefonie.

Web zbudowany z trzech prostych pomysłów

W istocie Web opiera się na praktycznym trio:

• URL (Uniform Resource Locator): adres czegoś w Sieci (strona, obraz, plik, endpoint).
• HTTP (Hypertext Transfer Protocol): konwersacja dostawy — jak przeglądarka żąda zasobu, a serwer odpowiada.
• HTML (HyperText Markup Language): format strony — struktura opisująca zawartość i, co istotne, linki do innych URL.

Nie musisz być programistą, żeby odczuć ich wpływ: za każdym razem, gdy wklejasz link, ładujesz stronę lub klikasz przycisk prowadzący gdzieś indziej, korzystasz z URL + HTTP + HTML.

Web a Internet (to nie to samo)

Ludzie często używają „Web” i „Internet” wymiennie, ale to różne rzeczy:

• Internet to infrastruktura: globalna sieć połączonych komputerów.
• Web to jedna z usług działających na niej: powiązana kolekcja zasobów dostępnych przez URL i HTTP, zwykle prezentowanych w HTML.

E‑mail, gry online czy wiele aplikacji czatowych używa Internetu bez bycia „Webem” w ścisłym sensie.

Dlaczego to nadal ma znaczenie

Nawet współczesne doświadczenia — aplikacje jednostronicowe, aplikacje mobilne czy API — dalej mocno polegają na tych fundamentach. Mogą ukrywać detale, ale nadal używają URL do identyfikowania zasobów, HTTP do wymiany żądań i odpowiedzi, a często HTML do uruchomienia tego, co widzisz w przeglądarce.

Problem, który Tim Berners‑Lee chciał rozwiązać

Tim Berners‑Lee nie próbował wynaleźć „internetu”. W 1989 roku, pracując w CERN, zajmował się praktyczną frustracją: ważne informacje istniały, ale były rozproszone po niekompatybilnych systemach, zapisywane w różnych formatach i trudno było je potem odnaleźć.

Badacze, zespoły i wydziały korzystały z różnych komputerów i oprogramowania. Nawet jeśli dwie grupy miały „ten sam” dokument, mogły przechowywać go w różnych miejscach, nadawać różne nazwy lub wymagać specjalnego programu do otwarcia. Udostępnianie często oznaczało wysyłanie plików, duplikowanie kopii i gubienie informacji o aktualnej wersji.

Prosty cel: uczynić informacje łączalnymi i łatwymi do udostępniania

Główny pomysł Berners‑Lee polegał na tym, by każdy mógł opublikować dokument na swoim komputerze, a inni mogli uzyskać do niego dostęp w spójny sposób — bez potrzeby znajomości typu maszyny, systemu operacyjnego czy wewnętrznej struktury katalogów.

To wymagało, by kilka elementów ze sobą współgrało:

• sposób jednoznacznego nazywania i lokalizowania informacji (adresy)
• podstawowy sposób żądania i odbierania informacji przez sieć
• lekki format dokumentu, który mógł zawierać linki do innych dokumentów

Prostota i interoperacyjność na pierwszym miejscu

Przełomem nie była pojedyncza funkcja — była to decyzja, aby system był mały i uniwersalny. Jeśli zasady były wystarczająco proste, różne komputery i organizacje mogły je zaimplementować i nadal się porozumiewać.

Dlatego od początku ważne były otwarte standardy: Web potrzebował wspólnych, publicznych reguł, aby wiele niezależnych systemów mogło w nim uczestniczyć. Skupienie się na standardach — zamiast na narzędziach jednego dostawcy — pozwoliło webowi szybko się rozprzestrzenić, a nowym przeglądarkom i serwerom działać z istniejącą treścią.

URL: system adresowania dla Web

Jeśli kiedykolwiek próbowałeś „udostępnić plik” na chaotycznym dysku sieciowym, widziałeś sedno problemu: nadawanie jednolitych nazw to trudne zadanie. Różne komputery przechowują dane w różnych miejscach, foldery są reorganizowane, a dwa pliki mogą mieć tę samą nazwę. Bez wspólnego systemu nazewnictwa nie da się niezawodnie powiedzieć „pobierz to tutaj”.

URL rozwiązał to dla World Wide Web, dając uniwersalny, kopiowalny adres zasobu.

URL, który możesz odczytać

Oto przykład, który możesz rozpoznać:

https://www.example.com:443/products/shoes?color=blacksize=42#reviews

Co oznacza każda część (po ludzku):

• https — schemat: jakie zasady zastosować do pobrania (HTTP przez szyfrowanie).
• www.example.com — host: z którym serwerem się komunikować.
• :443 — port (często domyślny i ukrywany).
• /products/shoes — ścieżka: który zasób na tym serwerze.
• ?color=blacksize=42 — query: dodatkowe parametry (często filtrowanie lub śledzenie).
• #reviews — fragment: pozycja w obrębie strony (obsługiwana przez przeglądarkę).

URL nie wskazuje tylko „stron”

URL może identyfikować praktycznie wszystko, co serwer potrafi zwrócić: stronę HTML, obraz, PDF, plik do pobrania czy nawet endpoint API używany przez aplikację.

Na przykład:

• /images/logo.png (obraz)
• /docs/terms.pdf (dokument)
• /api/orders/123 (dane dla aplikacji)

URL vs. URI vs. „link” (prosto)

Często te słowa używane są zamiennie:

• URL: „adres” w sieci, którego używasz, by coś pobrać.
• URI: szersze pojęcie, obejmujące URL.
• Link: to, co klikasz — zwykle tekst lub przycisk zawierający URL.

Na co dzień myślenie „URL = adres” wystarczy w około 95% przypadków.

HTTP: język żądań i odpowiedzi Web

HTTP to podstawowy styl rozmowy w sieci. To prosta umowa: twoja przeglądarka pyta o coś, a serwer odpowiada tym, co ma (lub wyjaśnieniem, dlaczego nie może tego dostarczyć).

Podstawowa idea: przeglądarka pyta, serwer odpowiada

Kiedy wpisujesz URL lub klikasz link, przeglądarka wysyła żądanie HTTP do serwera. Żądanie to notatka: „Chcę ten konkretny zasób”.

Serwer odsyła odpowiedź HTTP — paczkę zawierającą rezultat: treść, o którą prosiłeś (np. stronę), albo informację, że stało się coś innego.

Żądania w codziennych słowach (GET i POST)

Żądania HTTP zawierają metodę, czyli rodzaj akcji, którą wykonujesz.

• GET: „Proszę, daj mi to.” Przykład: ładowanie strony lub pobieranie pliku.
• POST: „Przyjmij te dane.” Przykład: wysyłanie formularza rejestracji lub komentarza.

GET zwykle nic nie zmienia po stronie serwera; służy głównie do odczytu. POST używa się, gdy wysyłasz dane do przetworzenia.

Kody statusu: wynik żądania

Każda odpowiedź zawiera kod statusu — pomyśl o nim jak o rezultacie doręczenia.

• 200: Sukces. Oto, o co prosiłeś.
• 404: Nie znaleziono. Ten zasób nie istnieje pod tym adresem.
• 301: Przeniesiono na stałe. Zasób ma nowy adres; zaktualizuj zakładkę.

Nagłówki i typy treści: etykiety na paczce

Żądania i odpowiedzi zawierają również nagłówki, które są jak etykiety: „Kim jestem”, „Co akceptuję” czy „Jak traktować tę treść”.

Jedną z najważniejszych etykiet jest Content-Type, np. text/html dla strony web lub application/json dla danych. Mówi przeglądarce, co jest w środku, żeby mogła to poprawnie wyświetlić.

HTML: prosty format stron i linków

HTML to format opisujący strukturę strony — co się na niej znajduje i jak jest zorganizowane. Traktuj go jak dokument z etykietami: „to nagłówek”, „to akapit”, „to link”, „to pole formularza”.

Tagi: etykiety wokół treści

HTML używa tagów do oznaczania treści. Tag zwykle ma wersję otwierającą i zamykającą, obejmując zawartość, którą opisuje.

Nagłówki i akapity nadają stronie kształt. Nagłówek mówi ludziom i przeglądarce: „to ważny tytuł sekcji”. Akapit oznacza „to tekst główny”.

Linki i obrazy też są opisane w HTML. Tag obrazka wskazuje plik obrazka (zasób), a tag linku wskazuje inny URL.

Hypertext: dlaczego linki wszystko zmieniły

„HT” w HTML — hypertext — to kluczowy pomysł, który odróżnił web od wcześniejszych systemów. Zamiast poruszać się tylko poprzez menu, foldery czy specjalne polecenia, można było skakać bezpośrednio z jednego dokumentu do drugiego, klikając linki osadzone w tekście.

To proste, ale potężne: wiedza staje się połączona. Strona może od razu odwołać się do źródeł, powiązanych tematów, definicji i dalszych kroków — bez konieczności wracania do centralnego indeksu.

Mały przykład: link po ludzku

Oto, jak wygląda podstawowy link:

\u003ca href=\"/blog/how-http-works\"\u003eRead more about HTTP\u003c/a\u003e

Po ludzku: „Pokaż słowa Read more about HTTP i po kliknięciu zabierz czytelnika do strony /blog/how-http-works."

Formularze: od czytania do interakcji

HTML nie służy tylko do publikowania dokumentów. Opisuje też pola wejściowe: pola tekstowe, checkboxy i przyciski. Te elementy pozwalają stronie zbierać informacje (logowanie, wyszukiwanie, checkout) i wysyłać je do serwera.

HTML vs. CSS vs. JavaScript

Łatwo je pomylić, ale pełnią różne role:

• HTML definiuje strukturę i znaczenie (nagłówki, akapity, linki, formularze).
• CSS kontroluje wygląd (kolory, odstępy, czcionki, układ).
• JavaScript dodaje zachowanie (walidacja, dynamiczne aktualizacje, interaktywność).

Nawet gdy aplikacje webowe stały się bardziej złożone, HTML pozostaje punktem wyjścia: wspólny, czytelny sposób opisania zawartości strony — i tego, dokąd ona prowadzi.

Jak ładuje się strona: krok po kroku po ludzku

Gdy odwiedzasz stronę, przeglądarka wykonuje zasadniczo dwie rzeczy: znajduje właściwy komputer, z którym się połączyć, i prosi o właściwy plik.

1) Wpisujesz URL

URL (np. https://example.com/page) to adres strony. Zawiera nazwę hosta (example.com) i często ścieżkę (/page).

2) Przeglądarka znajduje stronę (zapytanie DNS)

Komputery w internecie komunikują się używając numerów — adresów IP. DNS (Domain Name System) to książka telefoniczna, która mapuje example.com na adres IP.

To zwykle szybkie — czasem pomijane, bo wynik jest zapisany z poprzedniej wizyty.

3) Przeglądarka łączy się z komputerem

Przeglądarka otwiera połączenie z serwerem o tym adresie IP. Jeśli URL zaczyna się od https://, przeglądarka dodatkowo ustawia szyfrowane połączenie, by inni nie mogli łatwo odczytać przesyłanych danych.

4) Przeglądarka pyta za pomocą HTTP

HTTP to „język” żądania i odpowiedzi. Przeglądarka wysyła żądanie: „Proszę o /page.”

Serwer odpowiada statussem (np. „OK” lub „Nie znaleziono”) i treścią.

5) Przeglądarka otrzymuje HTML i renderuje stronę

Ta treść to często HTML. HTML opisuje strukturę strony — nagłówki, akapity, linki itd.

W trakcie parsowania HTML przeglądarka może odkryć, że potrzebuje dodatkowych plików (CSS, JavaScript, obrazy, fonty) i dla każdego powtarza wzorzec żądanie/odpowiedź HTTP.

6) Caching: „zapisanie kopii, by ładować szybciej”

Aby przyspieszyć ładowanie, przeglądarki przechowują cache — kopię plików. Jeśli nic się nie zmieniło, przeglądarka może użyć tej kopii zamiast pobierać ją ponownie.

Szybka lista kroków:

• Wpisz URL
• DNS znajduje adres IP
• Przeglądarka łączy się (i szyfruje, jeśli HTTPS)
• Żądanie HTTP o ścieżkę/zasób
• Serwer wysyła HTML (i inne pliki)
• Przeglądarka renderuje; cache przyspiesza kolejne wizyty

Serwery, przeglądarki i zasoby: podstawowe role

Gdy mówimy „web”, mamy na myśli płynne doświadczenie: dotknij linku i pojawia się strona. Pod spodem to proste relacje między trzema pojęciami: serwery, przeglądarki i zasoby.

Serwery: gdzie to się znajduje

Serwer to komputer (lub klaster), podłączony do internetu, który hostuje zasoby pod URL. Jeśli URL to adres, serwer to miejsce, które odbiera odwiedzających pod tym adresem i decyduje, co odesłać.

To, co serwer odsyła, może być stroną, plikiem lub danymi. Kluczowe jest, że serwer jest skonfigurowany do reagowania na żądania dla określonych URL.

Przeglądarki: które proszą i pokazują

Przeglądarka (np. Chrome, Safari, Firefox) to program, który pobiera zasoby z serwerów i wyświetla je w sposób zrozumiały dla ludzi.

Kiedy wpisujesz URL lub klikasz link, przeglądarka:

• prosi serwer o zasób pod tym URL
• odbiera odpowiedź
• renderuje ją (dla HTML) lub zapisuje/używa (dla obrazów, pobrań itp.)

Zasoby: co jest przesyłane

Zasób to wszystko, co web może zidentyfikować i dostarczyć pod URL. Przykłady:

• dokumenty (strony HTML)
• obrazy (PNG, JPEG, SVG)
• skrypty (pliki JavaScript)
• style (pliki CSS)
• API (endpointy zwracające dane, często JSON)

Model ten nie ogranicza się do przeglądarek. Aplikacja mobilna też może zażądać URL — zazwyczaj endpointu API — i otrzymać dane do wyświetlenia we własnym interfejsie. Role są te same: aplikacja jako „klient”, serwer jako „host” i odpowiedź API jako zasób.

Od dokumentów do interakcji: formularze i dane

Wczesne strony web zwykle tylko pokazywały informacje. Formularze pozwalają stronie zbierać informacje — to zmienia stronę w rozmowę dwu‑stronną.

Co właściwie robi formularz

Formularz HTML to zestaw pól (pola tekstowe, checkboxy, przyciski) oraz dwie kluczowe instrukcje:

• gdzie wysłać dane (URL w action)
• jak je wysłać (metoda method, zwykle GET lub POST)

Po kliknięciu „Submit” przeglądarka pakuje wpisane dane i wysyła je przez HTTP do serwera pod wskazany URL. To most między „dokumentem z polami” a „aplikacją, która te dane przetwarza”.

GET vs POST (praktyczna różnica)

W skrócie:

• GET dołącza dane formularza do URL jako query string (używane do wyszukiwań i filtrów). Wynik łatwo zapamiętać i udostępnić.
• POST wysyła dane w ciele żądania HTTP (używane przy tworzeniu lub zmienianiu czegoś, np. konta czy zamówienia).

Dlatego wyszukiwanie może wyglądać jak /search?q=shoes (GET), a realizacja zamówienia — jak wysłanie danych zamówienia do /checkout (POST).

Jak serwer „obsługuje” formularz

Po stronie serwera program odbiera żądanie HTTP, czyta przesłane wartości i decyduje, co dalej:

• waliduje dane (pola wymagane, poprawny format e‑mail)
• sprawdza uprawnienia (logowanie)
• tworzy rekordy (rejestracje, zgłoszenia)
• obsługuje płatności i potwierdza zamówienia (checkout)

Serwer odpowiada — często nową stroną HTML („Dziękujemy!”), komunikatem o błędzie lub przekierowaniem na inny URL.

Krótkie ostrzeżenie bezpieczeństwa: dlaczego HTTPS jest ważne

Jeśli formularz zawiera czułe dane — hasła, adresy, dane płatnicze — HTTPS jest niezbędny. Zapobiega to podsłuchiwaniu lub modyfikacji tego, co przesyłane jest między przeglądarką a serwerem. Bez niego nawet prosty formularz logowania może ujawnić dane użytkownika.

Dlaczego nowoczesne aplikacje dalej opierają się na URL, HTTP i HTML

Współczesne „aplikacje” Web to nie tylko strony. To często HTML, który ładuje JavaScript i CSS, a kod ten aktualizuje widok bez przeładowania całej strony.

Nawet gdy aplikacja zachowuje się jak program natywny (nieskończone przewijanie, aktualizacje w czasie rzeczywistym, drag‑and‑drop), i tak bazuje na tych trzech fundamentach Tim Berners‑Lee.

URL nadal identyfikuje wszystko

URL to nie tylko „strona”. To adres dowolnego zasobu: produktu, profilu użytkownika, zapytania wyszukiwania, zdjęcia czy endpointu „wyślij wiadomość”. Dobre aplikacje używają URL, by uczynić treści łatwymi do udostępniania, zapamiętywania i linkowania.

HTTP dalej przesyła wiadomości

W tle aplikacje wysyłają żądania HTTP i otrzymują odpowiedzi, tak jak klasyczne strony. Reguły są te same, niezależnie czy pobierasz stronę HTML, czy ładujesz dane dla fragmentu ekranu:

• metody: GET (odczyt), POST (wysyłanie), PUT/PATCH (aktualizacja), DELETE (usuwanie)
• kody statusu: 200, 404, 500
• nagłówki: cache, typ treści, autoryzacja

API to „strony web dla danych”

Wiele aplikacji komunikuje się z API: URL zwracający dane — często JSON — przez HTTP.

Na przykład:

• funkcja map pobiera pobliskie miejsca z API map
• proces checkout wysyła dane płatności do API płatniczego
• czat pobiera wiadomości i wysyła nowe do endpointu messaging
• analytics wysyła zdarzenia do endpointu analitycznego

HTML nadal ma znaczenie jako punkt startowy (i czasem jako fallback). Szerzej rzecz biorąc, Web to platforma integracji: jeśli systemy zgadzają się co do URL i HTTP, mogą się łączyć — niezależnie, kto je stworzył.

Praktyczny sposób, by zobaczyć te elementy w działaniu, to zbudować coś małego — np. frontend w React komunikujący się z JSON API i mający udostępnialne URL dla kluczowych ekranów. Narzędzia takie jak Koder.ai wykorzystują ten sam model: opisujesz aplikację w czacie, a narzędzie generuje standardowy stos webowy (React na froncie, Go + PostgreSQL na backendzie), więc dalej pracujesz z prawdziwymi URL, endpointami HTTP i HTML dostarczonym przez przeglądarkę — tylko z mniejszą ilością ręcznej konfiguracji.

Standardy i kompatybilność: jak skaluje się Web

Web działa w skali globalnej, bo opiera się na wspólnych standardach — publicznych „zasadach ruchu”, które pozwalają różnym systemom komunikować się niezawodnie. Przeglądarka jednej firmy może poprosić stronę z serwera innej firmy, hostowaną gdziekolwiek, napisaną w dowolnym języku, bo wszyscy zgadzają się co do podstaw: URL, HTTP i HTML.

Dlaczego standardy są ważne

Bez standardów każda strona wymagałaby dedykowanej aplikacji do jej oglądania, a każda sieć miałaby własny, prywatny sposób wysyłania żądań. Standardyzacja rozwiązuje proste, ale krytyczne pytania:

• Jak nazwać zasób? (URL)
• Jak klient o niego poprosi i go otrzyma? (HTTP)
• Jak zbudować wynik, żeby można go było wyświetlić i linkować? (HTML)

Gdy reguły są spójne, Web staje się „mix and match”: dowolna zgodna przeglądarka + dowolny zgodny serwer = działa.

Standardy ewoluują — bez łamania Web

Imponujące jest to, że standardy mogą się poprawiać, a fundamenty pozostają rozpoznawalne. HTTP ewoluował przez HTTP/1.1, HTTP/2 i HTTP/3, dodając wydajność i efektywność. Jednak idea pozostaje ta sama: klient żąda URL, serwer odpowiada kodem statusu, nagłówkami i ciałem.

HTML również się rozwinął — od prostych dokumentów do bogatszych semantyk i osadzonych mediów — zachowując podstawową koncepcję stron i hiperłączy.

Wsteczna zgodność to cecha, nie przypadek

Duża część trwałości Web wynika z preferencji dla wstecznej zgodności. Nowe przeglądarki nadal próbują renderować stare strony; nowe serwery rozumieją starsze żądania HTTP. Dzięki temu treść i linki mogą przetrwać lata — często dekady.

Projektowanie na przyszłość

Jeśli chcesz, by twoja strona lub aplikacja starzała się dobrze, opieraj się na standardach: używaj realnych URL do udostępnialnych stanów, postępuj zgodnie z konwencjami HTTP dotyczącymi cache i kodów statusu, oraz pisz poprawny HTML zanim dodasz dodatkowe warstwy. Standardy nie ograniczają — to one sprawiają, że twoja praca jest przenośna, niezawodna i przyszłościowa.

Powszechne nieporozumienia (i szybkie naprawy)

Nawet jeśli korzystasz z web codziennie, kilka terminów jest mylonych tak często, że może to zakłócić rozwiązywanie problemów, planowanie czy proste rozmowy. Oto powszechne pomyłki i najszybsze sposoby ich poprawienia.

„Internet” vs „Web”

Błąd: Internet i World Wide Web to to samo.

Szybka poprawka: Internet to globalna sieć (kable, routery, połączenia). Web to usługa działająca na niej, zbudowana z URL, HTTP i HTML.

URL vs domena (i dlaczego dodatkowe części mają znaczenie)

Błąd: „Mój URL to example.com.”

Szybka poprawka: example.com to domena. URL to pełny adres, który może zawierać ścieżkę i zapytanie, np.:

• https://example.com/pricing
• https://example.com/search?q=shoes

Te dodatkowe części mogą zmienić, co serwer zwraca.

HTML vs HTTP

Błąd: HTML i HTTP są zamienne.

Szybka poprawka: HTTP to „rozmowa dostawy” (żądanie i odpowiedź). HTML to jeden z możliwych „pakunków” dostarczanych — często opis strony i jej linków. HTTP może też dostarczać JSON, obrazy, PDF czy wideo.

Kody statusu i przekierowania

Błąd: Każdy błąd oznacza „strona padła”, a przekierowania są zawsze złe.

Szybka poprawka: Kody statusu to sygnały:

• 404: serwer osiągalny, ale zasób nie istnieje pod danym URL
• 500: błąd wewnętrzny serwera
• 301/302: przekierowanie (często normalne po przeniesieniu strony)

„URL zawsze wskazuje stronę”

Błąd: Każdy URL powinien otwierać stronę czytelną dla człowieka.

Szybka poprawka: URL może wskazywać dane (/api/orders), plik (/report.pdf) lub endpoint akcji dla formularza.

HTTPS = godne zaufania?

Błąd: Jeśli jest HTTPS, strona jest bezpieczna i uczciwa.

Szybka poprawka: HTTPS szyfruje połączenie i pomaga potwierdzić domenę, ale nie gwarantuje, że biznes jest wiarygodny. Nadal oceń źródło, treść i kontekst.

Najważniejsze wnioski i gdzie dowiedzieć się więcej

Główny pomysł Tima Berners‑Lee był zaskakująco prosty: łączyć dokumenty (a potem aplikacje) przy użyciu wspólnego schematu adresowania, wspólnego sposobu żądania danych i wspólnego formatu do ich wyświetlania.

Trzy bloki budulcowe (w jedną minutę)

URL to adres. Mówi co chcesz i gdzie się to znajduje (i często jak się do tego dostać).

HTTP to rozmowa. To zbiór reguł, których przeglądarka i serwer używają, by poprosić o coś i to otrzymać (kody statusu, nagłówki, cache i więcej).

HTML to format strony. To, co przeglądarka potrafi przeczytać, by wyrenderować zawartość — i co najważniejsze, gdzie linki łączą zasoby.

Powtarzalny model myślowy

Pomyśl o web jak o prostym trzyetapowym cyklu:

1. Nazwij (URL) — „Idź pod ten adres.”
2. Poproś (HTTP) — „Daj mi ten zasób.”
3. Pokaż i prowadź dalej (HTML) — „Oto znaczenie i dalsze ścieżki.”

Mając ten schemat w głowie, nowoczesne detale (cookies, API, single‑page apps, CDN) stają się łatwiejsze do zrozumienia: zwykle są to udoskonalenia nazewnictwa, żądania lub renderowania.

Gdzie dalej poczytać

Jeśli chcesz zgłębić temat bez nadmiernego technicznego detalu:

• HTTP w prostych słowach
• URL wyjaśniony
• HTML: podstawy i linki

Zrozumienie tych podstaw szybko się zwraca: lepiej oceniasz narzędzia webowe („Czy to polega na URL i standardowym HTTP?”), sprawniej komunikujesz się z deweloperami i łatwiej rozwiązujesz codzienne problemy, jak zepsute linki, niespodzianki związane z cache czy różnice między 404 a 500.