9 Opredeleniya metodov (Method Definitions).

Nabor obshchih metodov dlya HTTP/1.1 privoditsya nizhe. Hotya etot nabor mozhet byt' rasshiren, nel'zya schitat', chto dopolnitel'nye metody imeyut odinnakovuyu semantiku, esli oni yavlyayutsya rasshireniyami raznyh klientov i serverov.

Pole zagolovka zaprosa Host (razdel 14.23) DOLZHNO soprovozhdat' vse HTTP/1.1 zaprosy.

9.1 Bezopasnye i Idempotent metody.

9.1.1 Bezopasnye metody.

Programmistam sleduet ponimat', chto programmnoe obespechenie pri vzaimodejstvii s Internetom predstavlyaet pol'zovatelya, i programme sleduet informirovat' pol'zovatelya o lyubyh dejstviyah, kotorye on mozhet proizvesti, no kotorye mogut imet' nepredskazuemoe znachenie dlya nego ili drugih lic.

V chastnosti bylo prinyato soglashenie, chto metody GET i HEAD nikogda ne dolzhny imet' inogo znacheniya, krome zagruzki. |ti metody sleduet rassmatrivat' kak "bezopasnye". |to pozvolyaet agentam pol'zovatelya predstavlyat' drugie metody, takie kak POST, PUT i DELETE, takim obrazom, chtoby pol'zovatel' byl proinformirovan o tom, chto on zaprashivaet vypolnenie potencial'no opasnogo dejstviya.

Estestvenno, ne vozmozhno garantirovat', chto server ne generiruet pobochnye effekty v rezul'tate vypolneniya zaprosa GET; fakticheski, nekotorye dinamicheskie resursy soderzhat takuyu vozmozhnost'. Vazhnoe razlichie zdes' v tom, chto ne pol'zovatel' zaprashivaet pobochnye effekty, i, sledovatel'no, pol'zovatel' ne mozhet nesti otvetstvennost' za nih.

9.1.2 Idempotent metody.

Metody mogut takzhe obladat' svojstvom "idempotence" v tom smysle, chto pobochnye effekty ot N > 0 identichnyh zaprosov takie zhe, kak ot odinochnogo zaprosa (za isklyuchenie oshibok i problem ustarevaniya). Metody GET, HEAD, PUT i DELETE obladayut dannym svojstvom.

9.2 OPTIONS.

Metod OPTIONS predstavlyaet zapros informacii ob opciyah soedineniya, dostupnyh v cepochke zaprosov/otvetov, identificiruemoj zaprashivaemym URI (Request-URI). |tot metod pozvolyaet klientu opredelyat' opcii i/ili trebovaniya, svyazannye s resursom, ili vozmozhnostyami servera, no ne proizvodya nikakih dejstvij nad resursom i ne iniciiruya ego zagruzku.

Esli otvet servera - eto ne soobshchenie ob oshibke, to otvet NE DOLZHEN soderzhat' inoj informacii ob®ekta, krome toj, kotoruyu mozhno rassmatrivat' kak opcii soedineniya (naprimer Allow - mozhno rassmatrivat' kak opciyu soedineniya, a Content-Type - net). Otvety na etot metod ne keshiruyutsya.

Esli zaprashivaemyj URI (Request-URI) - zvezdochka ("*"), to zapros OPTIONS prednaznachen dlya obrashcheniya k serveru v celom. Esli kod sostoyaniya v otvete - 200, to otvetu SLEDUET soderzhat' lyubye polya zagolovka, kotorye ukazyvayut opcional'nye vozmozhnosti, realizuemye serverom (naprimer, Public), vklyuchaya lyubye rasshireniya, ne opredelennye dannoj specifikaciej, v dopolnenie k sootvetstvuyushchim obshchim polyam ili polyam zagolovka otveta (response-header). Kak opisano v razdele 5.1.2, zapros "OPTIONS *" mozhet byt' primenen cherez proksi-server s opredeleniem adresuemogo servera v zaprashivaemom URI (Request-URI) s pustym putem.

Esli zaprashivaemyj URI (Request-URI) ne zvezdochka ("*"), to zapros OPTIONS primenyaetsya k opciyam, kotorye dostupny pri soedinenii s ukazannym resursom. Esli kod sostoyaniya otveta - 200, to otvetu SLEDUET soderzhat' lyubye polya zagolovka, kotorye ukazyvayut opcional'nye vozmozhnosti, realizuemye serverom i primenimye k ukazannomu resursu (naprimer, Allow), vklyuchaya lyubye rasshireniya, ne opredelennye dannoj specifikaciej, v dopolnenie k sootvetstvuyushchim obshchim polyam ili polyam zagolovka otveta (response-header). Esli zapros OPTIONS peredaetsya cherez proksi-server, to poslednij redaktiruet otvet, isklyuchaya te opcii, kotorye ne predusmotreny vozmozhnosti etogo proksi-servera.

9.3 GET.

Metod GET pozvolyaet poluchat' lyubuyu informaciyu (v forme ob®ekta), identificirovannuyu zaprashivaemym URI (Request-URI). Esli zaprashivaemyj URI (Request-URI) obrashchaetsya k processu, proizvodyashchemu dannye, to v kachestve ob®ekta otveta dolzhny byt' vozvrashcheny proizvedennye dannye, a ne ishodnyj tekst processa, esli sam process ne vyvodit ishodnyj tekst.

Razlichaetsya "uslovnyj GET" ("conditional GET"), pri kotorom soobshchenie zaprosa vklyuchaet polya zagolovka If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, ili If-Range. Uslovnyj metod GET zaprashivaet peredachu ob®ekta, tol'ko esli on udovletvoryaet usloviyam, opisannym v uslovnyh polyah zagolovka. Uslovnyj metod GET prednaznachen dlya umen'sheniya nenuzhnoj zagruzki seti, i pozvolyaet obnovlyat' keshirovannye ob®ekty bez ispol'zovaniya neskol'kih zaprosov ili peresylki dannyh, uzhe sohranennyh klientom.

Razlichaetsya takzhe "chastichnyj GET" ("partial GET"), pri kotorom soobshchenie zaprosa vklyuchaet pole zagolovka Range. CHastichnyj GET zaprashivaet peredachu tol'ko chasti ob®ekta, kak opisano v razdele 14.36. CHastichnyj metod GET prednaznachen dlya umen'sheniya nenuzhnoj zagruzki seti, i pozvolyaet sobirat' ob®ekty iz chastej, bez peredachi chastej dannyh, uzhe sohranennyh klientom.

Otvet na zapros GET keshiruem togda i tol'ko togda, kogda on otvechaet trebovaniyam HTTP keshirovaniya, opisannym v razdele 13.

9.4 HEAD.

Metod HEAD identichen GET, za isklyucheniem togo, chto server NE DOLZHEN vozvrashchat' v otvete telo soobshcheniya (message-body). Metainformacii, soderzhashchejsya v HTTP zagolovkah otveta na zapros HEAD SLEDUET byt' identichnoj informacii, predstavlyaemoj v otvet na zapros GET. |tot metod mozhet ispol'zovat'sya dlya polucheniya metainformacii ob ob®ekte zaprosa bez neposredstvennoj peresylki tela ob®ekta (entity-body). |tot metod chasto ispol'zuetsya dlya testirovaniya gipertekstovyh svyazej v celyah proverki pravil'nosti, dostizhimosti, i vremeni modifikacii.

Otvet na zapros HEAD mozhet byt' keshiruemym v tom smysle, chto informaciya, soderzhashchayasya v otvete mozhet ispol'zovat'sya dlya modificikacii predvaritel'no keshirovannogo ob®ekta iz etogo resursa. Esli novye znacheniya polya ukazyvayut, chto keshiruemyj ob®ekt otlichaetsya ot tekushchego ob®ekta (po takim parametram, kak Content-Length, Content-MD5, ETag ili Last-Modified), to kesh DOLZHEN obrabatyvat' soderzhimoe kak prosrochennoe.

9.5 POST.

Metod POST ispol'zuetsya dlya zaprosa, pri kotorom adresuemyj server prinimaet ob®ekt, vklyuchennyj v zapros, kak novoe podchinenie resursa, identificirovannogo zaprashivaemym URI (Request-URI) v stroke zaprosa (Request-Line). POST razrabotan dlya togo, chtoby obshchim metodom realizovat' sleduyushchie funkcii:

Annotaciya sushchestvuyushchih resursov;
Registraciya soobshcheniya na elektronnoj doske ob®yavlenij (bulletin board), v konferencii novostej (newsgroup), spiske rassylki (mailing list), ili podobnoj gruppe statej;
Peredacha bloka dannyh, naprimer rezul'tat vvoda v forme, processu obrabotki;
Rasshirenie bazy dannyh posredstvom konkateniruyushchej operacii (append operation).

Fakticheski funkciya, vypolnyaemaya metodom POST, opredelyaetsya serverom i obychno zavisit ot zaprashivaemogo URI (Request-URI). Ob®ekt, peredavaemyj metodom POST, otnositsya k etomu URI takim zhe obrazom, kak fajl otnositsya k katalogu, v kotorom on nahoditsya, stat'ya otnositsya k konferencii novostej (newsgroup), v kotoroj ona zaregistrirovana, a zapis' otnositsya k baze dannyh.

Dejstvie, vypolnyaemoe metodom POST mozhet ne davat' v kachestve rezul'tata resurs, kotoryj mozhno bylo by identificirovat' URI. V etom sluchae, v zavisimosti ot togo, vklyuchaet li otvet ob®ekt, opisyvayushchij rezul'tat, ili net, kod sostoyaniya v otvete mozhet byt' kak 200 (OK), tak i 204 (Net soderzhimogo, No Content).

Esli resurs byl sozdan na pervonachal'nom servere, otvetu SLEDUET soderzhat' kod sostoyaniya 201 (Sozdan, Created) i vklyuchat' ob®ekt, kotoryj opisyvaet sostoyanie zaprosa i ssylaetsya na novyj resurs, a takzhe zagolovok Location (smotrite razdel 14.30).

Otvety na etot metod ne keshiruemy, esli otvet ne vklyuchaet sootvetstvuyushchie polya zagolovka Cache-Control ili Expires. Odnako, otvet s kodom sostoyaniya 303 (Smotret' drugoj, See Other) mozhet ispol'zovat'sya dlya perenapravleniya agenta pol'zovatelya dlya zagruzki keshiruemogo resursa.

Zaprosy POST dolzhny otvechat' trebovaniyam peredachi soobshcheniya, izlozhennym v razdele 8.2.

9.6 PUT.

Zaprosy s metodom PUT, kotorye soderzhat ob®ekt, sohranyayutsya pod zaprashivaemym URI (Request-URI). Esli Request-URI obrashchaetsya k uzhe sushchestvuyushchemu resursu, vklyuchennyj ob®ekt SLEDUET rassmatrivat' kak modificirovannuyu versiyu ob®ekta, nahodyashchegosya na pervonachal'nom servere. Esli Request-URI ne ukazyvaet na sushchestvuyushchij resurs, i mozhet interpretirovat'sya agentom pol'zovatelya kak novyj resurs dlya zaprosov, pervonachal'nyj server mozhet sozdat' resurs s dannym URI. Esli novyj resurs sozdan, to pervonachal'nyj server DOLZHEN soobshchit' agentu pol'zovatelya ob etom posredstvom otveta s kodom sostoyaniya 201 (Sozdan, Created). Esli sushchestvuyushchij resurs modificirovan, to dlya ukazaniya uspeshnogo zaversheniya zaprosa SLEDUET poslat' otvet s kodom sostoyaniya libo 200 (OK), libo 204 (Net soderzhimogo, No Content). Esli resurs ne mozhet byt' sozdan ili izmenen dlya zaprashivaemogo URI (Request-URI), to SLEDUET poslat' otvet, otrazhayushchij harakter problemy. Poluchatel' ob®ekta NE DOLZHEN ignorirovat' zagolovkov Content-* (naprimer Content-Range), kotoryh ne ponimaet ili ne realizuet, a DOLZHEN v dannom sluchae vozvratit' otvet s kodom sostoyaniya 501 (Ne realizovano, Not Implemented).

Esli zapros peredaetsya cherez kesh i zaprashivaemyj URI (Request-URI) identificiruet odin ili neskol'ko keshirovannyh v nastoyashchee vremya ob®ektov, to vhozhdeniya v kesh etih ob®ektov dolzhny obrabatyvat'sya kak prosrochennye. Otvety na etot metod ne keshiruemy.

Fundamental'noe razlichie mezhdu POST i PUT zaprosami, otrazheno v razlichnom znachenii zaprashivaemogo URI (Request-URI). URI v zaprose POST identificiruet resurs, kotoryj obrabatyvaet vklyuchennyj ob®ekt. |tim resursom mozhet byt' process, prinimayushchij dannye, shlyuz k nekotoromu drugomu protokolu, ili otdel'nyj ob®ekt, kotoryj prinimaet annotacii (accepts annotations). Naprotiv, URI v zaprose PUT identificiruet ob®ekt, vklyuchennyj v zapros - agent pol'zovatelya naznachaet dannyj URI vklyuchennomu resursu, a server NE DOLZHEN pytat'sya primenit' zapros k nekotoromu drugomu resursu. Esli server zhelaet primenit' zapros k drugomu URI, on DOLZHEN poslat' otvet s kodom 301 (Peremeshchen postoyanno, Moved Permanently); agent pol'zovatelya MOZHET zatem prinyat' sobstvennoe reshenie otnositel'no perenaznacheniya zaprosa.

Odinochnyj resurs MOZHET byt' identificirovan neskol'kimi razlichnymi URI. Naprimer, stat'ya mozhet imet' URI identificiruyushchij "tekushchuyu versiyu", kotoryj otlichen ot URI, identificiruyushchego kazhduyu specificheskuyu versiyu. V etom sluchae, zapros PUT na obshchij URI mozhet otrazit'sya (may result) na neskol'kih drugih URI, opredelennyh serverom proishozhdeniya.

HTTP/1.1 ne opredelyaet kakim obrazom metod PUT vozdejstvuet na sostoyanie pervonachal'nogo servera.

Zaprosy PUT dolzhny podchinyat'sya trebovaniyam peredachi soobshchenij, izlozhennym v razdele 8.2.

9.7 DELETE.

Metod DELETE zaprashivaet pervonachal'nyj server ob udalenii resursa, identificiruemogo zaprashivaemym URI (Request-URI). |tot metod MOZHET byt' otmenen chelovecheskim vmeshatel'stvom (ili drugimi sredstvami) na pervonachal'nom servere. Klientu nel'zya garantirovat', chto operaciya byla vypolnena, dazhe esli kod sostoyaniya, vozvrashchennyj pervonachal'nym serverom ukazyvaet na to, chto dejstvie bylo zaversheno uspeshno. Odnako, serveru NE SLEDUET otvechat' ob uspeshnom vypolnenii, esli vo vremya otveta on predpolagaet udalit' resurs ili peremestit' ego v nedostupnoe polozhenie.

Uspeshnomu otvetu SLEDUET imet' kod sostoyaniya 200 (OK), esli otvet vklyuchaet ob®ekt, opisyvayushchij sostoyanie, libo imet' kod sostoyaniya 202 (Prinyato, Accepted), esli dejstvie eshche ne bylo proizvedeno, libo imet' kod sostoyaniya 204 (Net soderzhimogo, No Content), esli otvet soobshchaet ob uspehe (OK), no ne soderzhit ob®ekta.

Esli zapros peredaetsya cherez kesh i zaprashivaemyj URI (Request-URI) identificiruet odin ili neskol'ko keshirovannyh v nastoyashchee vremya ob®ektov, to vhozhdeniya ih dolzhny obrabatyvat'sya kak prosrochennye. Otvety na etot metod ne keshiruemy.

9.8 TRACE.

Metod TRACE ispol'zuetsya dlya vyzova udalennogo vozvrata soobshcheniya zaprosa na urovne prilozheniya. Konechnomu poluchatelyu zaprosa SLEDUET otrazit' poluchennoe soobshchenie obratno klientu kak telo ob®ekta otveta s kodom sostoyaniya 200 (OK). Konechnym poluchatelem yavlyaetsya libo server proishozhdeniya, libo pervyj proksi-server, libo pervyj shlyuz, poluchivshij nulevoe znachenie (0) v pole Max-Forwards v zaprose (sm. razdel 14.31). Zapros TRACE NE DOLZHEN soderzhat' ob®ekta.

TRACE pozvolyaet klientu videt', chto poluchaetsya na drugom konce cepochki zaprosov i ispol'zovat' eti dannye dlya testirovaniya ili diagnosticheskoj informacii. Znachenie polya zagolovka Via (razdel 14.44) predstavlyaet osobyj interes, tak kak ono dejstvuet kak sled cepochki zaprosov. Ispol'zovanie polya zagolovka Max-Forwards pozvolyaet klientu ogranichivat' dlinu cepochki zaprosov, chto yavlyaetsya poleznym pri testirovanii beskonechnyh ciklov v cepochke proksi-serverov, peresylayushchih soobshcheniya.

Esli zapros uspeshno vypolnen, to otvetu SLEDUET soderzhat' vse soobshchenie zaprosa v tele ob®ekta (entity-body), a Content-Type sleduet byt' ravnym "message/http". Otvety na etot metod NE DOLZHNY keshirovat'sya.