HTML Forms: komunikacja z backendem bez JavaScriptu
Najprostszy frontend potrafi komunikować się z backendem bez jednej linii JavaScriptu. Wystarczy formularz.
<form method="post" action="/users">
<input name="name">
<button type="submit">Create</button>
</form>
Po kliknięciu przycisku przeglądarka wykonuje kilka konkretnych kroków:
- zbiera kontrolki należące do formularza,
- koduje ich wartości,
- buduje żądanie HTTP,
- wysyła je do
action, - odbiera odpowiedź,
- traktuje ją jako nową nawigację dokumentu.
To istotne: formularz nie jest „API helperem”. Jest częścią mechanizmu nawigacji przeglądarki.
GET i POST
Dla:
<form method="get" action="/search">
<input name="q" value="http">
</form>
przeglądarka utworzy:
GET /search?q=http HTTP/1.1
Host: example.com
Dane trafiają do query stringa.
Dla:
<form method="post" action="/users">
wartości trafiają do body:
POST /users HTTP/1.1
Content-Type: application/x-www-form-urlencoded
name=Alice
Domyślne kodowanie formularza to:
application/x-www-form-urlencoded
Pliki wymagają zwykle:
<form method="post" enctype="multipart/form-data">
Wtedy body składa się z części oddzielonych boundary.
Request powoduje nawigację
Najważniejsza cecha klasycznego formularza jest dziś jednocześnie jego ograniczeniem.
Po odpowiedzi:
HTTP/1.1 200 OK
Content-Type: text/html
browser zastępuje bieżący dokument nowym HTML-em.
To daje bardzo prosty model:
document
|
v submit
HTTP request
|
v
backend
|
v
HTML response
|
v
new document
Stan interfejsu istniejący wyłącznie w DOM lub JavaScript runtime znika razem z dokumentem.
Redirect po POST
Jeżeli backend po utworzeniu zasobu zwróci od razu HTML, odświeżenie strony może ponownie wykonać POST.
Dlatego klasyczny wzorzec to Post/Redirect/Get:
POST /users
|
v
303 See Other
Location: /users/123
|
v
GET /users/123
Backend wykonuje mutację tylko w POST, a końcowy dokument jest ładowany przez GET.
To nadal jeden z najczystszych modeli obsługi formularzy.
Co właściwie rozwiązuje formularz?
Formularz łączy trzy rzeczy:
UI state
+ serialization
+ navigation
Przeglądarka sama:
- zbiera dane,
- koduje request,
- obsługuje cookies,
- wysyła żądanie,
- interpretuje odpowiedź,
- aktualizuje historię nawigacji.
Cena jest oczywista: każda interakcja związana z backendem może oznaczać załadowanie całego dokumentu.
Dla dokumentowej natury webu było to wystarczające. Dla interfejsów przypominających aplikacje desktopowe już nie.
Potrzebny był sposób, żeby wykonać HTTP request bez nawigacji.
I właśnie to zmienił AJAX.