Szóval, pihenésre van szüksége a webes alkalmazások
Mi REST?
Szokásos átlag webes alkalmazás kezeli kétféle kérések: GET vagy POST és fogadására és küldésére adatok, ill. De RESTful építészet magában foglalja használja a teljes körű kérések: GET - kap az adatokat, POST - küldjön új adatokat, tegye - az általa szerkesztett adatokat Törlés - törli az adatokat. Van patch, ami annak elképzeléseit ismételjük, az egyetlen különbség az, hogy fel magában teljesen helyettesíti a rekordot, és a patch csak részben frissíteni az adatokat. Milyen érdekes, vélemények a használatát POST és PUT eltérnek. Angol nyelvű fejlesztők inkább a feltett új adatokat, POST szerkesztésre.
A példa a GML REST
Először is meg kell határozni a forrásokat, amelyek a felhasználó kölcsönhatásba léphet. A GML kaptam: kapcsolatok (linkek webes forrásokat), gyűjtemények (konténerek rekord), a felhasználók és címkék. Ezek a négy fő egységből, ahol a munka folyik.
Jelöljük a root domain a gml.link/
Megszereztük az alábbi adatok iránti kérelmeket:
- GET gml.link/links/ - teljes hivatkozások listája
- GET gml.link/links/125 - kap száz huszonötödik kapcsolat
- GET gml.link/collections/ - egy listát az összes gyűjtemények
- GET gml.link/collection/34 - kap egy listát a linkeket a harmincnegyedik gyűjtemény
- GET gml.link/tags/ - kap egy listát az összes tag
- GET gml.link/tags/animal - kap egy listát a linkeket címkéjű „állat” (a kulcsszó működik, mint egy azonosítót a nevét, nem egy szám.)
Kéri, hogy adjunk adatok (zárójelben feltüntetett adatok átvitele a szervezet a kérelem)
- POST gml.link/users/ (felhasználónév: 'Alex', jelszó: 'sdf7665 $ 6', e-mail: '[email protected]') - Új felhasználó hozzáadása
- POST gml.link/users/23 (felhasználónév: „Alex”, jelszó: „sdf7665 $ 6”, e-mail: "[email protected]) - ebben az esetben térjen vissza a hibát, ahogy rámutatott a kérés egy adott felhasználói azonosító
- POST gml.link/collections/ (címe: 'New Collection', 'típus': 'magán') - létrehoz egy új magángyűjtemény
Kéri a szerkesztéshez
- PUT gml.link/collections/ (címe: "A megváltozott szegmens neve) - hibát ad vissza, mert nincs megadva gyűjtemény azonosítóját
- PUT gml.link/collections/12 (címe: "A módosított cím a gyűjtemény) - változtassa meg a nevét a gyűjtemény a tizenkettedik
- PUT gml.link/links/117 (címe: „Egy másik név kapcsolat”) - változás a nevét a 117. linket
eltávolítási kérelmek
- DELETE gml.link/collection/32 - távolítsa el a harminc másodperces gyűjtemény
- DELETE gml.link/links/43 - távolítsa el a negyvenharmadik kapcsolat
Egy kicsit a technikai végrehajtás
(Megjegyzés olvassa ezt a bekezdés, az életed örökre megváltozik)
Mivel nem vagyunk Habrahabr, úgyhogy érinti a technikai végrehajtás próbaidőre.
Minden lekérdezés feldolgozása van osztva több szakaszból áll:
- Meghatározása forrás, amelyre a kérelem irányul (linkek, gyűjtemények, a felhasználók és a címkéket, és az erőforrás-azonosító)
- Meghatározása az akció kérés típusa (megszerzése, hozzátéve, szerkesztése és törlése)
- Gyűjtemény további paramétereket a lekérdezés (adni \ edit - közvetlenül az erőforrás adatokat előállítani - ezek különböző szűrők)
Mik az előnyei ennek az építészeti megközelítés?
Alkalmazása pihenni a projekt magam, tudomásul veszi a következőket:
Mi a következő lépés? (Általában)
Mint már mondtam, én írni a cikket, mint a végrehajtás egy részét a szolgáltatás. Abban a pillanatban, készen regisztrációs / hitelesítés, teljes mértékben támogatja a REST architektúra, végre „lusta terhelés” feltöltés link, add / hozzon létre egy gyűjtemény.
-- Mentése állapota oldalon keresztül HTML5 History API (mint a bónusz)
Ismét nagyon közvetetten kapcsolódik a REST API
-- Nem téveszthető össze több átviteli paraméterek kérelmek és feldolgozását, a szerver
Csak kezdődik a zavart. Amelyek áthaladnak a GET paramétereket, valami POST-on keresztül ugyanabban a felvezető.
-- Átlátszó kliensoldali alkalmazás logikáját
-- Szükség esetén, könnyedén biztosítani RESTful API harmadik féltől származó alkalmazások
És a másik protokoll nem biztosítja ezt a lehetőséget?
A REST sok bizonytalanság van, és emiatt minden jön a saját kivitelezés, amelyek szerintük a viszonyítási alap.
Nem kevésbé egyértelmű meghatározását. Mint például a hiba válasz:
1. HTTP-kód
2. Mindig 200 hibainformációkkal válaszként
Az 1. és 3. 2. opció
Válasz formátumban. Nevezzük a módszere, felhasználói:
1. [
2.
3.
Valaki, akit szeret, és nem. A nagy mínusz, ha meg kell integrálni több szolgáltatás.
A móka akkor kezdődik, amikor igények túlmutatnak az egyszerű túlmenően, kap egy listát, távolítsa el (tipikus szifilisz), azaz túlmutatnak /: gyűjtemény /: id
Itt van olyan suschnost akik tulajdonságok és módszerek. Mivel ezek az intézkedések végrehajtásához?
1. POST /: gyűjtemény /: id / on
2. Transzfer az „akció” a POST testet
3. Vagy általános használatban, PUT, patch
Egy kis probléma merül fel, ha van egy cross-browser kérés (CORS) a mi API-t. Minden URL (/: gyűjtemény /: id) küld előzetes OPTIONS kérés, további késleltetést.
Hozzáadott GET / Patch / DELETE handler /: gyűjtemény /: id. És azt akarjuk, hogy a böngésző-alapú alkalmazások ispolzvat jsonp, hogy megszabaduljon CORS politikát. Mi lesz, hogy újabb processzor (3 az 1-ben), hogy támogassa jsonp (ő GET esetén).
Nem standratyh service description által WSDL típusát. Pontosabban több vagy kevesebb, mint a széles körben használják.
Egy tipikus REST API, a dokumentáció és paraméterek leírása kézzel. Dokumentáció mindig elmarad.