16 komentářů k článku JavaScript na serveru: REST API:

  1. langpa

    POST vs PUT

    Jde o to, že by s PUT by nemělo spojeno moc magie, prostě vytvoří nebo nahradí obsah tak jak je.
    POST oproti tomu může magicky působit, protože může k resource přistupovat inkrementálně, přidávat a odebírat tagy a pod.

    Toto je přibližný a doplněný překlad z stackoverflow­.com. Resource nepřekládám… (dá se překládat jako zdroj/zdroje, ale je to zbytečně matoucí)

    POST:
    Používá se k úpravě nebo aktualizaci existujícího resource:
    POST /otazky/<existujici-otazka> HTTP/1.1
    Host: blahblah.cz

    Ne však k vytvoření neexistujícího resource, toto je chybné použití:
    POST /otazky/<nova-otazka> HTTP/1.1
    Host: blahblah.cz
    Pokud resource na URL není ještě vytvořen, neměla by se POST metoda používat k vytvoření. Takový požadavek na server by měl být zodpovězen jako 404 Not Found.
    Na druhou stranu stejný PUT požadavek na server by měla resource vytvořit a odpovědět kódem 201 Created (nebo 303)

    Je ale možné udělat něco takového pro vytvoření resource pomocí POST:
    POST /otazky HTTP/1.1
    Host: blahblah.cz
    Rozdíl je v tom, že v tomto případě není jméno resource uvedeno v URL. V tomto případě by měl server odpovědět URL na které se vytvořený resource nachází.

    PUT:
    Používá se k:
    – vytvoření, pokud resource na URL neexistuje, server odpoví 201 Created
    – přepsání, úplnému nahrazení resource, pokud již existuje, server odpoví 202 Accepted

    Pro vytvoření resource:
    PUT /otazky/<nova-otazka> HTTP/1.1
    Host: blahblah.cz

    Pro přepsání existujícího resource:
    PUT /questions/<e­xisting_questi­on> HTTP/1.1
    Host: wahteverblahblah­.com

    Jakube, omlouvám se jestli jsem to nezachytil, když jsem článek revidoval, tak alespoň tady… :-)

    1. langpa

      Re: POST vs PUT

      Jenom ještě dodám, že RESTfull APIs nejsou exaktní věda :-) Prostě je potřeba mít trochu citu, alespoň stručnou dokumentaci a hlavně integrační testy!

    2. jistr

      Re: POST vs PUT

      Souhlasím, pouze bych opravil toto:

      „PUT — přepsání, úplnému nahrazení resource, pokud již existuje, server odpoví 202 Accepted“ S tímto nesouhlasím, PUT by měl většinou odpovídat 200 OK, pokud server operaci dokončil před odesláním odpovědi klientovi.

      Kód 202 Accepted se používá, pokud operace nebyla dokončena před odesláním odpovědi, a je jedno jestli to byl POST, PUT nebo DELETE. Kód 202 naznačuje klientovi, že poslal správně formulovaný požadavek, ale že operace není ještě hotova. Klient pak většinou používá periodický polling ke zjištění, zda už operace proběhla.

      1. langpa

        polling

        Díky za připomínku, zní to logicky. Jen by mě zajímalo jak probíhá následný polling. Klient pošle GET požadavek a dostane celý obsah, nebo může posílat HEADER, pokud ho zajímá pouze stavový kód?

  2. Alblaho

    Není serizál zbytečně rozvleklý?

    Seriál se mi líbí, ale mám pocit, že zbytečně odbíhá od tématu. Pitvání různých HTTP kódů mi přijde zbytečné. Chci více nodejs, méně věcí kolem.

    Jinak „sort“ je přesnější překládat jako řazení. Třídění je rozklad množiny do tříd.

    1. Jakub MrozekAutor příspěvku

      Re: Není serizál zbytečně rozvleklý?

      Děkuji za reakci. Původně měl být článek delší a jeho druhá část měla být věnována úpravě aplikace podle popsané teorie + další informace o zajímavých Node.js modulech v oblasti REST, ale bohužel tento týden jsem měl mnohem méně času, a tak jsem se rozhodl článek rozdělit na dvě části. Předchozí tři díly zabraly každý minimálně 6 až 7 hodin a tento týden jsem seriálu tolik času věnovat nemohl.

      Popsaná teorie mi přijde důležitá pro celý zbytek seriálu. Programoval jsem systém, na kterém dnes běží cca 100 e-shopů a téměř každý obsahoval požadavky na import a export dat do nějakého dalšího systému. Viděl jsem jich desítky a s čistým svědomím můžu říct, že všechny do jednoho měly řadu chyb v návrhu, kvůli kterém byla implementace napojení vždy část, která zabrala nejvíce času.

      Seriál je nyní ve fázi vytváření prostředí pro vývoj v Node.js (hosting, databáze, testovací prostředí atd.) a tato fáze je již téměř u konce. V dalších částech seriálu bude zaměření čistě na Node.js větší a budu rycheji postupovat v tvorbě vzorové aplikace, která díky tomu může být reálná a schopná produkčního nastavení místo aplikace, která je pouze lepší „Hello World“.

      Překlad sort opravíme, děkuji.

      1. Fen

        Re: Není serizál zbytečně rozvleklý?

        Ja si zase myslim, ze je to pojato vhodne. Jen je skoda toho rozdeleni na 2 samostatne clanky. Priklanel bych se i k brzkemu popisu autorizace a autentifikace :) Serial se mi dost libi (to poznam tak, ze netrpelive cekam, az vyjde dalsi dil ;D), takze jen tak dal.

  3. http://xdexter.id.seznam.cz/

    Node.js autorizace a autentizace

    Dobrý den,
    v článku zmiňujete, že se budete věnovat v dalších dílech autorizaci a autentizaci. Chtěl bych se zeptat, jaké moduly (knihovny) na autorizaci a autentizaci používáte (dříve jste se již zmínil o Passport a Everyauth)?

    Děkuji.

    1. Jakub MrozekAutor příspěvku

      Re: Node.js autorizace a autentizace

      Dobrý den,

      omlouvám se za pozdní odpověď, Váš příspěvek jsem přehlédl. Jak píšete, Passport a Everyauth jsou nejpopulárnější moduly. Nejprve jsem používal Everyauth, později jsem ale přešel na Passport, protože do Everyauth se dost těžko vstupuje, potřebuje-li člověk udělat něco trochu jinak. Kromě toho Passport je lépe otestován (viz issues na Githubu u obou projektů). Kromě těchto modulů se často ještě zmiňuje mongoose-auth (https://github.com/bnoguchi/mongoose-auth), což je plugin pro Mongoose postavený na Everyauth, s ním ale zkušenosti nemám. Jinak modulů pro tuto oblast je v Node.js velké množství, jejich přehled lze nalézt na https://npmjs.org/browse/keyword/auth.

  4. langpa

    Testování REST API

    Ještě zde zmíním výborný český (nikoli počeštěný) startup na testování RESTfull APIs: apiary.io.
    Určitě stojí za to vyzkoušet.

      1. langpa

        Re: Testování REST API

        Ačkoli naši čeští kluci odvedli skvělou práci, nemyslím si, že by se o jejich výtvor měl opírat nějaký další článek v seriálu. Paralelně o tom může napsat někdo jiný (že Adame :-) ), ale myslím, že už zevrubným popisem RESTfull API se seriál zaměřený primárně na node odebírá trochu jiným směrem než měl cílit a to je trochu škoda, ne pro teď, ale jako „návod“ někdy v budoucnu tím trochu trpí.

        1. Jakub MrozekAutor příspěvku

          Re: Testování REST API

          Jsou to dva odstavce na konci článku, to si myslím, že nevadí. A odstavce se vztahují tomu, co se vytváří, zmínka o nich do článku patří. Je těžké v českém seriálu o Node.js a REST API nezmínit Apiary, český startup pro REST API v Node.js:-)

  5. M3dard

    děkuji za článek a dotaz

    V současné době se s použitím REST architektury setkávám stále častěji a začínám jí i implementovat do svých aplikací.
    Proto mi pomohl hezký seznam kódů používaných pro odpověď. Jak jsem zjistil, používal jsem některé špatně.
    Zajímalo by mě také, zda pro zvolení formátu komunikace není jednoduší používat na konci URL příponu formátu „.json“ nebo „.xml“. Protože použití hlavičky s accept požadavkem se mi zdá, hlavně při GET dotazech, u kterých není potřeba autorizace, zbytečně složité.
    Jinak moc děkuji za hezký článek, který teda toho neměl moc společného s nodeJS :-))

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3737