0 comments Postanowiłem przypomnieć sobie wzorce projektowe i natrafiłem na bardzo fajne repozytorium (Design Patterns PHP), które obfitowało w opisy konkretnych wzorców z przykładami realizacji w PHP. Brakowało polskiego tłumaczenia. Dlatego, aby połączyć przyjemne z pożytecznym, przetłumaczyłem całą dokumentację na polski.
2 comments Poniższy tekst jest mniej lub bardziej udanym tłumaczeniem artykułu Choosing an HTTP Status Code — Stop Making It Hard :).
Nie ma rzeczy prostszej niż zwrócenie kodu odpowiedzi HTTP. Strona się wyświetliła? Świetnie, zwróćmy kod 200. Strona nie istnieje? To kod 404. Przekierowujemy użytkownika na inną stronę? No to 302 albo 301.
Życie jest piękne dopóki ktoś powie Ci, że nie używasz REST-a. Nie możesz w nocy spać, bo zastanawiasz się, czy Twoja aplikacja zwraca zgodny z REST-em i zatwierdzony przez Roya Fieldinga kod odpowiedzi. Czy wystarczy 200? Czy powinien to być raczej 204 No Content? Nie, na pewno to powinien być 202 Accepted… a może jednak 201 Created?
To co komplikuje nam sytuację, to oficjalny standard HTTP/1.1, RFC, które pierwotnie powstało w 1997 roku (nie zawracaj sobie głowy RFC 2616, ani tym bardziej RFC 2068, zobacz RFC 7231). 1997 to rok, kiedy zacząłem przeglądać internet na Netscape Navigator i swoim modemie 33,6 kbps. To trochę jak używać Sztuki wojennej Sun Zi do współczesne strategii biznesowej. Nieśmiertelne rady, ale nie wyobrażam sobie jak wykorzystać pięć sposobów walki ogniem do testowania rynku.
Gdyby tylko istniał jakiś wizualny sposób na wybranie tylko tych istotnych kodów?
Proszę bardzo, internecie. Ten dzień nadszedł!
