Aký protokol aplikačnej vrstvy používa typy správ, ako je get put a post. Typy HTTP požiadaviek a filozofia REST. Ako funguje vzorová aplikácia

Pokiaľ tomu všetkému rozumiem, tak ak porovnáte operácie PUT a POST v MySQL, potom POST je INSERT a PUT je UPDATE alebo INSERT

Pozrime sa na príklad fóra. Má vlákna a príspevky. Dávame žiadosti do ahoj témy

POST / téma / ahoj? Správa = Tu POST / téma / ahoj? Správa = bol POST / téma / ahoj? Správa = Vasya

Prvá požiadavka vytvorí ( VLOŽIŤ) ahoj téma so správou „Tu“, ďalšie dve žiadosti tiež vytvoria ( VLOŽIŤ) nové príspevky v téme. Výsledkom je, že téma ahoj obsahuje: Vasya bola tu.

PUT / téma / ahoj? Správa = Sem PUT / téma / ahoj? Správa = bola PUT / téma / ahoj? Správa = Vasya

Prvá požiadavka vytvorí ( VLOŽIŤ) ahoj téma so správou „Tu“, ďalšie dve žiadosti sa aktualizujú ( AKTUALIZOVAŤ) správa v predmete. Výsledkom je, že téma hello obsahuje: Vasya.

Idempotencia PUT tu sa to prejavuje v tom, že počet správ v databáze počas nasledujúcich operácií zostáva nezmenený... Pokiaľ ide o odkazy, mapa stránok zostane nezmenená. Aktualizovaný bude iba obsah tém.

alebo: každý POST / článok / ahoj žiadosť bude vytvoriť nová kapitola v ahoj článku. Prvá požiadavka vytvorí samotný článok.

každý PUT / článok / ahoj žiadosť bude aktualizovať JEDINÁ kapitola v ahoj. Prvá požiadavka vytvorí samotný článok.

To je to, čo by nám GET mal vrátiť, ak sme POST urobili

GET / topic / hello 201 Vasya bol tu

V tomto prípade nám budú k dispozícii aj tieto URI.

GET / topic / hello / 1 201 Tu GET / topic / hello / 2 201 bolo GET / topic / hello / 3 201 Vasya

To je to, čo by nám GET mal vrátiť, ak sme urobili PUT

GET / téma / ahoj 201 Vasya

V tomto prípade budeme mať k dispozícii iba jeden URI.

GET / topic / hello / 1 201 Vasya GET / topic / hello / 2 404 GET / topic / hello / 3 404

PRÍKLAD #2 Príklad s používateľmi.

POST / používateľ / Eugen? Vek = 7 POST / používateľ / Eugen? Vek = 10 POST / používateľ / Eugen? Vek = 5

Vytvorí 3 používateľov s názvom eugen vo veku 7, 10, 5, resp.

PUT / používateľ / Eugen? Vek = 7 PUT / používateľ / Eugen? Vek = 10 PUT / používateľ / Eugen? Vek = 5

Vytvorí sa iba jeden používateľ menom eugen vo veku 5 rokov

Inými slovami: PUT povinný aktualizovať napíš, či tam už údaje sú

Preto váš príklad String userId = this.request ["USER_ID"]; s uložením hodnoty do premennej. Koľkokrát by ste si ľahli ( PUT) hodnoty do premennej - premenná bude vždy jedna.

Odtiaľ sa narodil PRÍKLAD #3

Neviem, do akej miery je toto prirovnanie pravdivé, ale myslím si, že toto tvrdenie bude pravdivé:

POST: push $ premenná, hodnota; - výsledkom je pole hodnôt PUT: $ premenná = hodnota; - vo výsledku jedna hodnota

v prípade POST môže dôjsť k preplneniu pamäte servera. V prípade PUT nie je na škodu, berú sa len kliešte ;-)

Mimochodom, našiel som dobrý zdroj o bezpečnosti a idempotencii.

Pri vývoji postupu na odosielanie informácií na stránku z 1C s verziou platformy 8.3.9.2170 som narazil na problém: vývojár stránky mi poskytol možnosť zaznamenať potrebné informácie iba pomocou požiadavky HTTP pomocou metódy PUT.

Bez rozmýšľania som si zapísal jednoduchý kód:

Pripojenie = Nové pripojenie HTTP („www.mysite.ru“); Nadpisy = Nová zhoda; Hlavičky ["Content-Type"] = "application / x-www-form-urlencoded"; Request = New HTTPRequest ("/ api / order_items / 93076? Order_item = 30", Headers); Connection.Write (Žiadosť);

Na základe výsledkov vykonania by malo byť množstvo tovaru prijatého na sklad zapísané na príslušnom riadku objednávky kupujúceho na webe.

Ako ste však už zrejme pochopili, nič sa nestalo. Keď som sa presvedčil, že na stránke nie sú žiadne chyby (odoslaním podobnej požiadavky cez doplnok Chrome), spustil som webový server na svojom lokálnom počítači a začal som experimentovať.

Okamžite sa vyjasnila zvláštna vec: vyššie uvedený kód negeneruje požiadavku PUT, ale požiadavku HEAD!

V protokoloch Apache som videl nasledovné:

127.0.0.1 - - "HEAD / api / order_items / 93076? Order_item = 30 HTTP / 1.1"

Bol som trochu prekvapený (v návode to bolo napísané čiernobielym PUT), ale nezmýlil som sa - metódu môžete zavolať priamo:

Connection.CallHTTPMetóda ("PUT", Požiadavka);

Logy sú rovnaké:

127.0.0.1 - - "HEAD / api / order_items / 93076? Order_item = 30 HTTP / 1.1"

"Možno robím niečo zle?" - položil som si otázku. Ale na internete a v manuáloch neboli žiadne stopy. Vedecká metóda poke ešte nebola zrušená. Najprv som sa pokúsil urobiť toto:

Connection.CallHTTPMethod ("fwfw", Požiadavka);

V protokoloch som dostal:

127.0.0.1 - - "?????? / api / order_items / 93076? Order_item = 30 HTTP / 1.1"

Je zvláštne, že to znamená, že 1C nahrádza metódu PUT konkrétne (prečo to nepotešilo 1C?).

Po niekoľkých ďalších pokusoch som prišiel s možnosťou:

Connection.CallHTTPMetóda ("PUT", Požiadavka);

V protokoloch som dostal:

127.0.0.1 - - "PUT / api / položky_objednávky / 93076? Položka_objednávky = 30 HTTP / 1.1"

A táto možnosť už na stránke fungovala a všetci boli spokojní.

Navrhol správnejšie riešenie problému: je potrebné nastaviť telo požiadavky, akékoľvek, aj prázdne. Napríklad táto možnosť bude fungovať:

Pripojenie = Nové pripojenie HTTP („www.mysite.ru“); Nadpisy = Nová zhoda; Hlavičky ["Content-Type"] = "application / x-www-form-urlencoded"; Request = New HTTPRequest ("/ api / order_items / 93076? Order_item = 30", Headers); Request.SetBodyFromString ("", TextCode.UTF8, UsingByteOrderMark.Nepoužívať); Connection.Write (Žiadosť);

A pravdepodobne je už celkom správne odovzdať samotné hodnoty parametrov v tele požiadavky.

Záver je nasledovný: platforma 1C považuje požiadavku PUT bez tela za chybnú a nahrádza metódu HEAD.

Je zvláštne, že 1C nesleduje požiadavku POST bez tela a žiadnym spôsobom ju nepremieňa na GET, bola skontrolovaná kvôli športovému záujmu.

Ako by povedal známy Malý Johnny zo slávnej anekdoty: "Kde je logika?"

Dúfam, že niekomu moja publikácia ušetrí pár hodín života pri hľadaní odpovede. =)))

15 odpovedí

HTTP PUT:

PUT umiestni súbor alebo prostriedok na konkrétny URI a presne na tento URI. Ak sa v tomto URI už nachádza súbor alebo prostriedok, PUT tento súbor alebo prostriedok nahradí. Ak tam nie je žiadny súbor alebo prostriedok, PUT ho vytvorí. PUT idempotentné, ale paradoxne, odpovede PUT nie sú cacheovateľné.

HTTP POST:

POST odosiela údaje na špecifický URI a očakáva, že zdroj na tomto URI spracuje požiadavku. Webový server v tomto bode môže určiť, čo robiť s údajmi v kontexte zadaného zdroja. Metóda POST nie je idempotentná, avšak odpovede POST možno uložiť do vyrovnávacej pamäte, ak server nastaví príslušné hlavičky Cache-Control a Expires.

Oficiálny HTTP RFC definuje POST ako:

• Anotácia existujúcich zdrojov;
• Uverejnenie správy na nástenku, diskusnú skupinu, zoznam adries alebo podobnú skupinu článkov;
• Poskytnutie bloku údajov, napríklad výsledku odoslania formulára, na spracovanie údajov;
• Rozšírenie databázy pomocou operácie add.

Rozdiel medzi POST a PUT:

Samotný RFC vysvetľuje hlavný rozdiel:

Hlavný rozdiel medzi požiadavkami POST a PUT sa odráža v rôznom význame identifikátora URI požiadavky. URI v požiadavke POST identifikuje zdroj, ktorý bude spracovávať súkromnú entitu. Tým zdrojom môže byť prijímací proces, brána pre nejaký iný protokol alebo samostatná entita, ktorá prijíma anotácie. Na rozdiel od toho URI v požiadavke PUT identifikuje objekt pripojený k požiadavke - užívateľský agent vie, čo je URI a server BY SA NEMAL pokúšať aplikovať požiadavku na iný zdroj. Ak si server želá, aby bola požiadavka aplikovaná na iné URI, MUSÍ poslať odpoveď 301 (presunutá trvalá); užívateľský agent potom MÔŽE urobiť vlastné rozhodnutie o tom, či má byť požiadavka presmerovaná.

Použitím správnej metódy, ktorá nie je prepojená:

Iba sémantika.

HTTP PUT má prevziať telo požiadavky a potom ho uložiť na zdroj identifikovaný pomocou URI.

HTTP POST je všeobecnejší. Predpokladá sa, že spustí akciu na serveri. Touto akciou môže byť uloženie tela požiadavky v zdroji identifikovanom URI, alebo to môže byť iné URI, alebo to môže byť iná akcia.

PUT , napríklad... Umiestnenie v URI ovplyvňuje toto konkrétne URI. Zverejnenie URI môže mať akýkoľvek účinok.

Príklady zdrojov štýlu REST:

"POST / knihy" s množstvom informácií o knihe môže vytvoriť novú knihu a odpovedať novou adresou URL identifikujúcou túto knihu: "/ books / 5".

"PUT / knihy / 5" bude musieť vytvoriť novú knihu s ID 5 alebo nahradiť existujúcu knihu s ID 5.

V štýle bez zdrojov sa POST dá použiť takmer na čokoľvek, čo má vedľajší účinok. Ďalším rozdielom je, že PUT musí byť idempotentný – viacero PUT rovnakých údajov pre rovnakú adresu URL musí byť presných, ak viacero POST môže vytvoriť viacero objektov alebo čokoľvek, čo robí vaša akcia POST.

1) GET: - používa sa, keď klient požaduje zdroj na webovom serveri.

2) HEAD: - používa sa, keď klient požaduje nejaké informácie o zdroji, ale nepožaduje samotný zdroj.

3) POST: - používa sa, keď klient posiela informácie alebo údaje na server, napríklad vyplnenie online formulára (t. j. odoslanie veľkého množstva komplexných údajov na webový server).

4) PUT: - Používa sa, keď klient odošle náhradný dokument alebo nahrá nový dokument na webový server pod adresou URL požiadavky.

5) DELETE: - Používa sa, keď sa klient pokúša vymazať dokument z webového servera určeného adresou URL požiadavky.

6) TRACE: - Používa sa, keď klient žiada dostupné proxy alebo sprostredkujúce servery, aby upravili požiadavku na reklamu.

7) MOŽNOSTI: - Používa sa, keď chce klient definovať iné dostupné metódy pre získanie alebo spracovanie dokumentu na webovom serveri.

8) CONNECT: - Používa sa, keď chce klient nadviazať transparentné spojenie so vzdialeným hostiteľom, zvyčajne na poskytovanie SSL šifrovanej komunikácie (HTTPS) cez HTTP proxy server.

Iní už zverejnili skvelé odpovede, len som chcel dodať, že pri väčšine jazykov, frameworkov a prípadov použitia budete veľa riešiť POST, oveľa častejšie ako PUT. V čase PUT, DELETE atď. Sú to väčšinou triviálne otázky.

Podľa RFC, rozdiel medzi PUT a POST je v URI požiadavky. Identifikátor URI identifikovaný testom POST definuje objekt, ktorý spracuje požiadavku POST. URI v požiadavke PUT zahŕňa objekt v požiadavke. Takže POST / v1 / coffees / orders znamená vytvorenie nového zdroja a vrátenie ID na popis zdroja. Na rozdiel od toho PUT / v1 / kávy / objednávky / 1234 znamená aktualizáciu zdroja označeného "1234", ak existuje; inak vytvorte novú objednávku a použite objednávky / 1234 URI na jej identifikáciu.

PUT a POST možno použiť na vytváranie alebo aktualizáciu metód. Použitie metódy závisí od idempotentného správania očakávaného od metódy, ako aj od umiestnenia zdroja na jeho identifikáciu.

POST sa považuje za niečo ako továrenskú metódu. Pripojíte k nemu dáta, aby ste vytvorili to, čo chcete, a čokoľvek je na druhom konci, vie, čo s tým má robiť. PUT sa používa na aktualizáciu existujúcich údajov na zadanej URL alebo na vytvorenie niečoho nového, keď viete, aké bude URI a ešte to neexistuje (na rozdiel od POST, ktorý niečo vytvorí a v prípade potreby vráti URL).

V poslednej dobe ma veľmi rozčuľuje populárna mylná predstava webových vývojárov, že POST sa používa na vytvorenie zdroja a PUT na aktualizáciu / úpravu.

Ak sa pozriete na stranu 55 RFC 2616 („Hypertext Transfer Protocol – HTTP / 1.1“), časť 9.6 („PUT“), môžete vidieť, že PUT je platný pre:

Metóda PUT požaduje, aby bol súkromný objekt uložený v dodanom identifikátore URI požiadavky.

Je tu tiež praktický odsek, ktorý vysvetľuje rozdiel medzi POST a PUT:

Hlavný rozdiel medzi požiadavkami POST a PUT sa odráža v rôznom význame identifikátora URI požiadavky. URI v požiadavke POST identifikuje zdroj, ktorý bude spracovávať uzavretý objekt. Týmto zdrojom môže byť proces prijímania údajov, brána do iného protokolu alebo samostatná entita, ktorá prijíma anotácie. Naproti tomu URI v požiadavke PUT identifikuje objekt priložený k požiadavke – užívateľský agent vie, čo je URI a server BY SA NEMAL pokúšať aplikovať požiadavku na iný zdroj.

Nehovorí nič o aktualizácii/vytvorení rozdielu, pretože to nič nie je. O rozdiele medzi týmto:

Obj.set_attribute (hodnota) # Požiadavka POST.

Obj.attribute = hodnota # Požiadavka PUT.

Prestaňte teda šíriť túto populárnu mylnú predstavu. Prečítajte si svoje RFC.

REST žiada vývojárov, aby používali metódy HTTP explicitne a spôsobom, ktorý je v súlade s definíciou protokolu. Tento základný princíp návrhu REST vytvára mapovanie typu one-to-one medzi operáciami vytvorenia, čítania, aktualizácie a vymazania (CRUD) a metódami HTTP. Podľa tohto mapovania:

Použite POST na vytvorenie prostriedku na serveri.

Ak chcete získať zdroj, použite GET.

Ak chcete zmeniť stav zdroja alebo ho aktualizovať, použite PUT.

Použite DELETE na odstránenie alebo odstránenie zdroja.

HTTP (anglicky HyperText Transfer Protocol - "Hypertext Transfer Protocol") je aplikačný protokol na prenos dát (pôvodne - vo forme hypertextových dokumentov vo formáte HTML). HTTP je založený na technológii klient-server, to znamená, že sa predpokladá, že existujú spotrebitelia (klienti), ktorí iniciujú spojenie a pošlú požiadavku, a poskytovatelia (servery), ktorí čakajú na spojenie, aby prijali požiadavku, vykonávajú potrebné akcie a vráti správu s výsledkom. HTTP je teraz všadeprítomný na World Wide Web na získavanie informácií z webových stránok.

HTTP sa používa aj ako „transport“ pre iné protokoly aplikačnej vrstvy ako SOAP, XML-RPC, WebDAV.

Hlavným predmetom manipulácie v HTTP je zdroj, na ktorý poukazuje URI (English Uniform Resource Identifier) ​​v požiadavke klienta. Tieto prostriedky sú zvyčajne súbory uložené na serveri, ale môžu to byť logické objekty alebo niečo abstraktné. Vlastnosťou protokolu HTTP je schopnosť špecifikovať v požiadavke a odpovedi spôsob, akým je ten istý zdroj reprezentovaný rôznymi parametrami: formát, kódovanie, jazyk atď. (Na to sa používa najmä hlavička HTTP.) vďaka možnosti špecifikovať spôsob kódovania správy si klient a server môžu vymieňať binárne dáta, hoci tento protokol je textový.

HTTP je protokol aplikačnej vrstvy, podobne ako FTP a SMTP. Správy sa vymieňajú podľa obvyklej schémy „požiadavka-odpoveď“. HTTP používa globálne identifikátory URI na identifikáciu zdrojov. Na rozdiel od mnohých iných protokolov je HTTP bezstavový. To znamená, že nedochádza k zachovaniu medzistavu medzi pármi požiadavka-odpoveď. Komponenty používajúce HTTP môžu nezávisle ukladať informácie o stave súvisiace s nedávnymi požiadavkami a odpoveďami (napríklad „cookies“ na strane klienta, „relácie“ na strane servera). Žiadajúci prehliadač môže sledovať oneskorenia odozvy. Server môže ukladať IP adresy a hlavičky požiadaviek najnovších klientov. Samotný protokol však nepozná predchádzajúce požiadavky a odpovede, neposkytuje internú štátnu podporu a ani takéto požiadavky nemá.

Výhody

Tento protokol je veľmi ľahko implementovateľný, je dobre rozšíriteľný vďaka zavedeniu vlastných hlavičiek, ktoré pridávajú funkcionalitu aplikácii a ktoré budú ignorované inými aplikáciami, ktoré ich považujú za neznáme:

Jednoduchosť. Protokol sa jednoducho implementuje, čo uľahčuje vytváranie klientskych aplikácií.

Rozšíriteľnosť. Možnosti protokolu možno jednoducho rozšíriť zavedením vlastných hlavičiek, pomocou ktorých získate potrebnú funkcionalitu pri riešení konkrétnej úlohy. Zároveň je zachovaná kompatibilita s inými klientmi a servermi: budú jednoducho ignorovať neznáme hlavičky.

Prevalencia. Pri výbere protokolu HTTP na riešenie konkrétnych problémov je dôležitým faktorom jeho rozšírenosť. Výsledkom je množstvo rôznych dokumentácií o protokole v mnohých jazykoch sveta, zahrnutie ľahko použiteľných vývojových nástrojov do populárnych IDE, podpora protokolu ako klienta mnohými programami a široký výber medzi hostingovými spoločnosťami so servermi HTTP.

Štruktúra protokolu

Každá správa HTTP pozostáva z troch častí, ktoré sa odosielajú v uvedenom poradí:

Počiatočná čiara - definuje typ správy;

Hlavičky - charakterizujú telo správy, prenosové parametre a ďalšie informácie;

Telo správy sú samotné údaje správy. Musí byť oddelené od hlavičiek prázdnym riadkom.

Hlavičky a telo správy môžu chýbať, ale úvodný riadok je povinný, pretože označuje typ požiadavky/odpovede. Výnimkou je verzia 0.9 protokolu, v ktorej správa s požiadavkou obsahuje iba začiatočný riadok a správy s odpoveďou obsahujú iba telo správy.

Štartovacia čiara

Začiatočné čiary sa líšia pre požiadavku a odpoveď. Reťazec dopytu vyzerá takto:

GET URI - pre verziu protokolu 0.9.

Metóda HTTP URI / Verzia - pre ostatné verzie.

Metóda (anglická metóda) – názov požiadavky, jedno slovo veľkými písmenami. V HTTP 0.9 bola použitá iba metóda GET, zoznam požiadaviek pre verziu 1.1 je uvedený nižšie.

URI definuje cestu k požadovanému dokumentu.

Verzia (anglická verzia) - dvojica čísel oddelených bodkou. Napríklad: 1.0

Štartovací riadok odpovede servera má nasledujúci formát: HTTP / Vysvetlenie kódu stavu verzie, kde:

Verzia - dvojica čísiel oddelených bodkami ako v požiadavke.

Stavový kód - tri číslice. Stavový kód určuje ďalší obsah správy a správanie klienta.

Reason Phrase je krátke textové vysvetlenie kódu odpovede pre používateľa. Nemá žiadny vplyv na správu a je voliteľná.

Počiatočná čiara odpovede servera na predchádzajúcu požiadavku môže napríklad vyzerať takto:

Metódy

Metóda HTTP je postupnosť ľubovoľných znakov, okrem riadiacich znakov a oddeľovačov, označujúca hlavnú operáciu so zdrojom. Obvykle je metódou krátke anglické slovo napísané veľkými písmenami. Všimnite si, že názov metódy rozlišuje veľké a malé písmená.

Každý server musí podporovať aspoň metódy GET a HEAD. Ak server nerozpozná metódu špecifikovanú klientom, potom by mal vrátiť stav 501 (neimplementované). Ak server pozná metódu, ale nie je použiteľná pre konkrétny zdroj, vráti sa správa s kódom 405 (metóda nie je povolená). V oboch prípadoch by server MAL do správy odpovede zahrnúť hlavičku Allow so zoznamom podporovaných metód.

Okrem metód GET a HEAD sa často používa metóda POST.

MOŽNOSTI Používa sa na definovanie možností webového servera alebo parametrov pripojenia pre konkrétny zdroj. Server BY MAL v odpovedi obsahovať hlavičku Allow so zoznamom podporovaných metód. Do hlavičky odpovede môžu byť zahrnuté aj informácie o podporovaných rozšíreniach.

Predpokladá sa, že žiadosť klienta môže obsahovať telo správy na označenie informácií, ktoré nás zaujímajú. Formát tela a poradie práce s ním nie sú v súčasnosti definované. Server by to mal zatiaľ ignorovať. Situácia je podobná s telom v odpovedi servera.

Aby klient zistil možnosti celého servera, musí v URI zadať hviezdičku - "*". MOŽNOSTI * Požiadavky HTTP / 1.1 možno použiť aj na testovanie stavu servera (podobne ako pri pingovaní) a na testovanie, či server podporuje HTTP 1.1.

Výsledok tejto metódy sa neukladá do vyrovnávacej pamäte.

Používa sa na dopytovanie obsahu zadaného zdroja. Proces môžete spustiť aj metódou GET. V tomto prípade by mala byť informácia o priebehu procesu zahrnutá do tela správy s odpoveďou.

Klient môže zadať parametre na vykonanie požiadavky v URI cieľového zdroja za znakom „?“:

GET / cesta / zdroj? Param1 = hodnota1 & param2 = hodnota2 HTTP / 1.1

Podobne ako pri metóde GET, s tým rozdielom, že v odpovedi servera chýba telo. Požiadavka HEAD sa zvyčajne používa na získanie metadát, kontrolu, či zdroj existuje (overenie adresy URL) a na zistenie, či sa zmenil od posledného prístupu k nemu.

Hlavičky odpovedí možno uložiť do vyrovnávacej pamäte. Ak sa metadáta zdroja nezhodujú s príslušnými informáciami vo vyrovnávacej pamäti, kópia zdroja sa označí ako zastaraná.

Používa sa na prenos používateľských údajov do daného zdroja. Napríklad na blogoch môžu návštevníci zvyčajne zadávať svoje komentáre k príspevkom do formulára HTML, potom sú odoslané na server a umiestnené na stránku. V tomto prípade sú prenášané údaje (v príklade s blogmi - text komentára) zahrnuté v tele žiadosti. Podobne pomocou metódy POST sa zvyčajne nahrávajú súbory na server.

Na rozdiel od metódy GET sa metóda POST nepovažuje za idempotentnú, to znamená, že viacnásobné opakovanie rovnakých požiadaviek POST môže vrátiť rôzne výsledky (napríklad po každom odoslaní komentára sa objaví ďalšia kópia tohto komentára).

Ak je výsledok vykonania 200 (Ok), správa o výsledku vykonania požiadavky by mala byť zahrnutá do tela odpovede. Ak bol vytvorený zdroj, server BY MAL vrátiť odpoveď 201 (Vytvorené) s URI nového zdroja v hlavičke Location.

Správa s odpoveďou servera na metódu POST nie je uložená do vyrovnávacej pamäte.

Používa sa na stiahnutie obsahu požiadavky na URI špecifikované v požiadavke. Ak zdroj na zadanom URI neexistoval, server ho vytvorí a vráti stav 201 (Vytvorené). Ak bol zdroj zmenený, server vráti 200 (OK) alebo 204 (Žiadny obsah). Server NESMIE ignorovať neplatné hlavičky Content- * odoslané klientom so správou. Ak niektorú z týchto hlavičiek nemožno rozpoznať alebo nie sú platné za aktuálnych podmienok, potom sa musí vrátiť kód chyby 501 (neimplementované).

Základný rozdiel medzi metódami POST a PUT je v pochopení účelu URI zdrojov. Metóda POST predpokladá, že obsah prenášaný klientom bude spracovaný na špecifikovanom URI. Použitím PUT klient predpokladá, že načítaný obsah sa zhoduje so zdrojom na danom URI.

Správy s odpoveďou servera na metódu PUT sa neukladajú do vyrovnávacej pamäte.

Podobné ako PUT, ale vzťahuje sa len na časť zdroja.

Odstráni zadaný zdroj.

Vráti prijatú požiadavku, aby klient mohol vidieť, aké informácie sprostredkujúce servery pridávajú alebo menia v požiadavke.

Priraďuje špecifikovaný zdroj k ostatným.

Odstráni priradenie zadaného zdroja k ostatným.

Konvertuje pripojenie požiadavky na transparentný TCP/IP tunel, zvyčajne na uľahčenie vytvorenia bezpečného pripojenia SSL cez nešifrovaný proxy server.

7 odpovedí

MESSAGE

HTTP.POST možno použiť, keď klient odošle údaje na server a server určí URI pre novovytvorený zdroj. Metóda POST sa používa na vyžiadanie, aby pôvodný server akceptoval objekt zahrnutý v požiadavke ako nový podriadený zdroj identifikovaný pomocou Request-URI v reťazci požiadavky.

UMIESTNENIE

HTTP.PUT možno použiť, keď klient odosiela údaje na server a klient zadáva URI pre novovytvorený prostriedok. Metóda PUT požaduje, aby bol vnorený objekt uložený pod dodaným identifikátorom URI požiadavky. Ak identifikátor URI požiadavky odkazuje na už existujúci zdroj, s vnoreným objektom BY SA MALI zaobchádzať ako s upravenou verziou nachádzajúcou sa na pôvodnom serveri. Ak identifikátor URI požiadavky neukazuje na existujúci zdroj a toto URI môže požadujúci užívateľský agent identifikovať ako nový zdroj, pôvodný server môže vytvoriť zdroj s týmto URI.

ZÁPLATA

HTTP.PATCH možno použiť, keď klient odošle jednu alebo viacero zmien, ktoré má server použiť. Metóda PATCH požaduje, aby sa množina zmien opísaná v objekte požiadavky použila na zdroj identifikovaný identifikátorom URI požiadavky. Sada zmien je prezentovaná vo formáte nazývanom opravný dokument.

Ďalšie informácie nájdete na nižšie uvedenej adrese URL

Rozdiel medzi PUT, POST, GET, DELETE a PATCH IN HTTP Verbs:

Najčastejšie používané HTTP slovesá POST, GET, PUT, DELETE sú obdobou operácií CRUD (Create, Read, Update and Delete) v databáze. Tieto HTTP slovesá špecifikujeme v prípade kapitál... Takže nižšie je porovnanie medzi nimi.

1. vytvoriť - POST
2. čítať - GET
3. aktualizácia - PUT
4. vymazať - VYMAZAŤ

NÁPRAVA: Poskytuje čiastočnú úpravu zdroja. Ak potrebujete aktualizovať iba jedno pole pre zdroj, môžete použiť metódu PATCH.

Poznámky:
Keďže POST, PUT, DELETE mení obsah, testy huslistov pre URL nižšie len napodobňujú aktualizácie. Neodstráni sa ani v skutočnosti nezmení. Môžeme sa len pozrieť na stavové kódy, aby sme skontrolovali, či existujú vloženia, aktualizácie, vymazania.

1) PRÍJEM:

GET je najjednoduchší spôsob, ako vytvoriť požiadavku HTTP; ten, ktorý prehliadače použijú pri každom kliknutí na odkaz, alebo zadajte adresu URL do panela s adresou. Inštruuje server, aby odovzdal údaje identifikované adresou URL klientovi. Údaje by sa na strane servera nemali meniť v dôsledku požiadavky GET. V tomto zmysle je požiadavka GET len na čítanie.

odpoveď: dostanete odpoveď ako:

"userId": 1, "id": 1, "title": "sunt aut ...", "body": "quia et suscipit ..."

Na ceste, „šťastný“ (alebo žiadna chyba), GET vráti reprezentáciu XML alebo JSON a kód odpovede HTTP 200 (OK). V prípade chyby zvyčajne vráti 404 (NOT FOUND) alebo 400 (BAD REQUEST).

2) Zverejniť:

Sloveso POST sa používa najmä pre tvorba nové zdroje. Používal najmä na vytváranie podriadených zdrojov. To znamená, že sa riadi iným (napríklad nadradeným) zdrojom.

Po úspešnom vytvorení vráťte stav HTTP 201 a vráťte hlavičku Location s odkazom na novovytvorený zdroj so stavom HTTP 201.

Kontrola u Fiddlera alebo Postmana: na otestovanie odpovede môžeme použiť huslistu. Otvorte skript a vyberte kartu Vytvoriť. Zadajte sloveso a adresu URL, ako je uvedené nižšie, a kliknutím na tlačidlo „Spustiť“ otestujte odpoveď.

Telo žiadosti:

údaje: (title: "foo", body: "bar", userId: 1000, Id: 1000)

Odpoveď. Dostanete kód odpovede 201.

Ak chceme skontrolovať vložený záznam s Id = 1000, zmeňte sloveso Get a použite rovnakú url a kliknite na tlačidlo Vykonať.

Ako už bolo povedané, vyššie uvedená adresa URL je len na čítanie (GET), aktualizované údaje nemôžeme čítať v reálnom čase.

PUT sa najčastejšie používa na príležitosti obnova Vloženie do URI známeho zdroja s telom požiadavky obsahujúcej aktualizovanú reprezentáciu pôvodného zdroja.

Kontrola u Fiddlera alebo Postmana: na otestovanie odpovede môžeme použiť huslistu. Otvorte skript a vyberte kartu Vytvoriť. Zadajte sloveso a adresu URL, ako je uvedené nižšie, a kliknutím na tlačidlo „Spustiť“ otestujte odpoveď.

Telo žiadosti:

údaje: (title: "foo", body: "bar", userId: 1, Id: 1)

Odpoveď. Po úspešnej aktualizácii vráti 200 (alebo 204, ak nevráti žiadny obsah v tele) z PUT.

4) VYMAZAŤ:

DELETE je celkom ľahké pochopiť. Používa sa na mazanie zdroj identifikovaný pomocou URI.

Po úspešnom odstránení vráťte stav HTTP 200 (OK) spolu s telom odpovede, možno vykreslením odstránenej položky (často si vyžaduje príliš veľkú šírku pásma) alebo zabalenou odpoveďou (pozri Návratové hodnoty nižšie). Buď to, alebo vrátiť stav HTTP 204 (ŽIADNY OBSAH) bez tela odpovede. Inými slovami, odporúčaná odpoveď je stav 204 bez tela alebo odpoveď JSEND a stav HTTP 200.

Kontrola u Fiddlera alebo Postmana: na otestovanie odpovede môžeme použiť huslistu. Otvorte skript a vyberte kartu Vytvoriť. Zadajte sloveso a adresu URL, ako je uvedené nižšie, a kliknutím na tlačidlo „Spustiť“ otestujte odpoveď.

sloveso: VYMAZAŤ

Odpoveď. Po úspešnom odstránení vráti stav HTTP 200 (OK) spolu s telom odpovede.

Príklad medzi PUT a PATCH

UMIESTNENIE

Ak by som si musel zmeniť meno, odošlite žiadosť o aktualizáciu PUT:

("first": "Nazmul", "last": "hasan") Takže tu, aby sme aktualizovali krstné meno, musíme znova odoslať všetky parametre údajov.

Žiadosť o opravu hovorí, že pošleme iba údaje, ktoré potrebujeme zmeniť, bez toho, aby sme zmenili alebo ovplyvnili iné časti údajov. Príklad: ak potrebujeme aktualizovať len krstné meno, odovzdáme len krstné meno.

Viac informácií nájdete na nižšie uvedených odkazoch:

PUT = nahradiť ÚPLNÉ ZDROJE novým pohľadom

PATCH = nahradiť časti pôvodného zdroja poskytnutými hodnotami AND | ALEBO sú aktualizované iné časti zdroja, ktoré ste poskytli (časové pečiatky) A | ALEBO aktualizované efekty zdrojov s inými zdrojmi (vzťahy)

GET / PUT - idempotentná náplasť môže byť niekedy idempotentná

Byť idempotentný znamená, že ak dopyt spustíme niekoľkokrát, nemalo by to ovplyvniť jeho výsledok (rovnaký výsledok. Predpokladajme, že krava je gravidná a ak ju znova rozmnožíme, nemôže byť tehotná niekoľkokrát).

získať: -

len si to. Získajte údaje zo servera a ukážte ich používateľovi

príspevok: -

vytvoriť nový zdroj v databáze. To znamená, že pridáva nové údaje. Toto nie je idempotent.

daj: -

Vytvorte nový zdroj, inak pridajte k existujúcemu. Idempotentný, pretože zakaždým aktualizuje rovnaký zdroj a výsledok bude rovnaký. napr.- počiatočné údaje

(id: 1 meno: parth email: [e-mail chránený] }

• spustiť put-localhost / 1 vložiť e-mail: [e-mail chránený]

(id: 1 email: [e-mail chránený] }

náplasť

takže teraz patch prišiel, požiadavka PATCH môže byť niekedy idempotentná

Id: 1 name: parth email: [e-mail chránený] }

Názov opravy: W

(id: 1 meno: w email: [e-mail chránený]) Metóda HTTP GET yes POST no PUT yes PATCH no * OPTIONS yes HEAD yes DELETE yes

Nižšie uvedená definícia je prevzatá z príkladu zo skutočného sveta.

Hrubý prehľad
Pre každú informáciu o klientovi ukladáme ID, aby sme našli údaje o klientovi, a toto ID pošleme klientovi na referenciu.

1. MESSAGE

   • Ak Klient odošle údaje bez ID metódou POST, uložíme ich a pridelíme nové ID.
   • Ak ich Klient odošle rovnakýúdaje bez id metódou POST uložíme a pridelíme nové id.
   • Poznámka: duplikácia je tu povolená

2. UMIESTNENIE

   • Ak Klient zasiela údaje s identifikátorom, overíme, či tento identifikátor existuje. Ak identifikátor existuje, údaje aktualizujeme, v opačnom prípade ho vytvoríme a pridelíme nový identifikátor.
3. • Ak Klient zasiela údaje s identifikátorom, overíme, či tento identifikátor existuje. Ak identifikátor existuje, aktualizujeme údaje, inak vyvoláme výnimku.

Poznámka. V metóde Dajte ak sa id nenájde, nevyhodíme výnimku. Ale v metóde Náplasť ak sa id nenájde, vyvoláme výnimku.

Ak máte nejaké otázky týkajúce sa vyššie uvedeného, ​​dajte nám vedieť.

Tu je rozdiel medzi metódami POST, PUT a PATCH protokolu HTTP.

POST

Metóda HTTP.POST vždy vytvorí nový zdroj na serveri. Ide o neidempotentný dotaz, t.j. Ak používateľ zadá rovnaké požiadavky 2-krát, vytvorí nový nový zdroj, ak neexistujú žiadne obmedzenia.

http metóda post je ako dotaz INSERT v SQL, ktorý vždy vytvorí nový záznam v databáze.

Príklad. Použite metódu POST na uloženie nového používateľa, objednávky atď., keď backend rozhodne o ID zdroja pre nový zdroj.

PUT

V metóde HTTP.PUT sa zdroj najprv identifikuje z adresy URL a ak existuje, potom sa aktualizuje, inak sa vytvorí nový zdroj. Keď cieľový zdroj existuje, prepíše tento zdroj úplne novým telom. Toto je metóda HTTP.PUT používaná na VYTVORENIE alebo AKTUALIZÁCIU zdroja.

Metóda http put je ako dotaz MERGE v SQL, ktorý vloží alebo aktualizuje záznam v závislosti od toho, či daný záznam existuje.

Požiadavka PUT je idempotentná, t.j. zadaním rovnakých dopytov sa dvakrát aktualizuje existujúci záznam (nevytvorí sa žiadny nový záznam). V metóde PUT je ID zdroja definované klientom a špecifikované v adrese URL požiadavky.

Príklad. Na aktualizáciu existujúceho používateľa alebo objednávky použite metódu PUT.

ZÁPLATA

Metóda HTTP.PATCH sa používa na čiastočné úpravy aktualizácie prostriedkov, teda delta aktualizácie.

Metóda opravy http je ako dotaz UPDATE v SQL, ktorý nastavuje alebo aktualizuje iba vybrané stĺpce a nie celý riadok.

Príklad. Na aktualizáciu stavu objednávky môžete použiť metódu PATCH.

PATCH / api / používatelia / 40450236 / objednávka / 10234557