Bevezetés a lekérés

Viszlát, XMLHttpRequest!

fetch () lehetővé teszi, hogy kéri, hasonló XMLHttpRequest (XHR). A fő különbség az, hogy lekérése API Promises (Promise). amelyek lehetővé teszik a nagyobb egyszerű és tiszta API, elkerülve a katasztrofális száma visszahívások, és annak szükségességét, hogy emlékezzen az API-t XMLHttpRequest.

Lekérése API elérhető a felhasználók számára a szolgáltatás munkás „s globális hatóköre a Chrome 40, de a változat 42 elérhetővé válik a Scope ablak. Természetesen minden más böngészők nem létezik még nem támogatják letölteni Polyphemus származó GitHub. ami ma elérhető.

Egyszerű lehívás kérése

Kezdjük az összehasonlítása egy egyszerű példát, megvalósított XMLHttpRequest és hozd. Mindent, amit mi ebben a példában - olyan kérelmet az URL, és feldolgozni a válasz megkapjuk azt JSON.

XMLHttpRequest

Példa XMLHttpRequest követeli meg tőlünk, hogy hozzanak két eseménykezelőkkel a siker és a hiba. valamint oka két módszer: nyitott (), és küldje (). Egy példa a MDN dokumentáció:

A lehívás kérése nézne ki:

Az első dolog, amit ellenőrizni az állapotát a választ, és ellenőrizze, hogy sikeresen végrehajtani egy lekérdezést (200 várják állapot). Ha minden rendben van, akkor elemezni a válasz JSON.

fetch () a patak-válasz objektumot. Ez azt jelenti, hogy ennek eredményeként a hívó JSON () metódus, megkapjuk a Promise, mint olvasni a hasonló célú aszinkron.

metaadatok válasz

Az előző példában, megtanultuk, hogyan kell ellenőrizni az állapotát a válasz tárgy és konventirovat saját válasza JSON. A többi metaadatok, amit esetleg hozzáférhetnek (pl fejezetek), az alábbiak:

Válasz típusok

Amikor fetch-kérés válasz típusú «alapvető» élveznek «Cors» vagy «átlátszatlan». Ezek a „típus” jelzi, milyen jött erőforrás-adatokat és fel lehet használni annak érdekében, hogy meghatározzák adatfeldolgozás.

Ha egy kérelmet az erőforrás található azonos eredetű (azaz a kérelem belül kerül sor egy oldalon. Kb. Per.) Válasz tartalmazza a típus „alap” és egy ilyen kérelem nem lesz semmilyen korlátozás.

Ha a kérelmet a másikra origin'a (cross site request), amely viszont visszatért CORS fejlécek, mivel típus lesz «Cors». Tárgyak a fajta «Cors» és «alapvető» majdnem azonos, de «Cors» valamelyest korlátozza a metaadatok, amelyek elérhetők a «Cache-Control», «Content-Language», «Content-Type», «lejár», «Last-Modified» és «Pragma».

Ami a «átlátszatlan» - jön azokban az esetekben, amikor egy CORS kérelmet, de a távoli erőforrás nem tér vissza CORS fejlécet. Ez a fajta lekérdezés nem biztosít hozzáférést az adatokhoz vagy cím állapotát, így nem tudjuk megítélni a lekérdezés eredményének. A jelenlegi végrehajtása fetch () nem lehet elvégezni CORS kéréseket köréből ablak, és ezért meg van írva itt. Ezt a funkciót ki kell egészíteni, amint a gyorsítótár API elérhető lesz az ablak.

Megadhatjuk a várható kérés módot, ezáltal szűrjük lekérdezés eredményét a megfelelő típusú. lekérdezés üzemmódban lehet beállítani a következő:

- „same-origin” sikerül csak kéréseket azonos eredetű, minden más kérelmeket elutasítják.
- „Cors” ugyanúgy működik, mint a «same-origin» + növeli a képességet, hogy hozza létre a lekérdezéseket a harmadik fél helyek, ha visszatérnek a megfelelő CORS fejléceket.
- „Cors-with-kénytelen-preflight” ugyanúgy működik, mint «Cors», de még mielőtt a kérést mindig küld egy próba felülvizsgálati kérelmet.
- „no-Cors” kifejezés, ha azt szeretné, hogy a lekérdezés eredetét, amely nem küld a CORS fejlécek, és az eredmény a végrehajtás egy objektum típusú «átlátszatlan». Mint már említettük, abban a pillanatban ez nem lehetséges, a terjedelem ablakban.

Meghatározásához lekérdezés módban, adjuk hozzá a lehetőségek célunk a második paraméter a kérelmet, és állítsa be az «üzemmód» ebben az objektumban:

láncok Promises

Az egyik szép tulajdonsága, hogy képes a Promise'ov csoport őket lánc. Ha beszélünk róluk, a terjedelem lekérés (). lehetővé teszik számunkra, hogy „fumble” logikai kérelmek között.

Ha dolgozni JSON API, akkor kell hogy ellenőrizze az állapotát, és feldolgozni JSON minden választ. Akkor egyszerűsíteni a kódot azonosítja az állapot és JSON elemzés külön visszatérő függvények Promise'y. Meg kell gondolni, csak a feldolgozás az adatok is, és természetesen kivételek.

Mi határozza meg, hogy a funkció ellenőrzi response.status és visszaadja az eredményt: Promise.resolve () vagy Promise.reject (). Ez az első módszer az úgynevezett mi láncban, és ha sikerül (Promise.resolve ()), majd hívta a következő módszer - fetch (). ami viszont ismét visszatér az ígéret response.json (). Miután ezt a hívást, ha sikeres, akkor lesz kész JSON objektumot. Ha nem sikerül elemzés, Promise törlésre kerül, és a munka feltétele a kivétel.

POST kérés

Régóta nem meglepő kell használni a POST módszert átadni paramétereket a „test” a kérés, hogy működjön együtt az API-t.
Elvégzésére az ilyen kérelmet, meg kell adnunk a megfelelő beállításokat a beállítások objektum fetch ():

Benyújtása hitelesítő keresztül kérhetik Fetch-

Ha azt szeretnénk, hogy küldjön egy kérést a megbízólevelét (pl süti), akkor a `credentials` opciók kérésre«közé»:

Lehet törölni a lekérés () lekérdezést?
Abban a pillanatban, hogy ez lehetetlen, de aktívan tárgyalt GitHubról

Van Polyphemus?
igen

Miért «no-Cors» végrehajtani dolgozókat, de nem az ablakon?
Ez azért történt, biztonsági okokból. További részletek itt találhatók.