Ahogy tettük a szociális hálózati API (a többi api az interneten)
Most nézzük sorrendben.
REST (reprezentációs State Transfer - Representational State Transfer).
REST (reprezentációs State Transfer - Representational State Transfer).
A szerkezet a REST API
1. A kliens-szerver architektúra
2. A hontalan szerver
4. A többrétegű szerkezet
5. Egyetlen kezelőfelület
- források azonosítása
- Kölcsönhatás források bemutatásán keresztül
- önálló üzenete
- Hipermédia alkalmazások az állami szabályozó mechanizmus (HATEOAS)
6. A kérelem kódja (nem kötelező)
Most minden egyes tételről részletesen.
Építészet, kliens - szerver. Elkülönítése az alkalmazás logikáját a különböző ügyfelek, hogy a kód könnyebben hordozható és szerver felépítés egyszerűbb és skálázható. A fejlesztés a kliens és a szerver végezhetjük teljesen függetlenül.
Hontalan - szerver. Ügyfél állapot nincs a szerveren tárolt bármilyen módon, hogy kizárólag a vevőnek. Ez leegyszerűsíti a befejezése és karbantartása a szerver, így stabilabb.
Gyorsítótárazhatók. világos rendszert cache kéréseket a szerver kell kidolgozni, amely jelentősen javítja a teljesítményt.
Többrétegű szerkezet. Jelenléte / hiánya közbenső szerverek, caching, terheléselosztás, további proxy kell maradnia teljesen észrevétlen marad az ügyfél.
forrás azonosítása. Minden erőforrás egyedi URI (Uniform Resource Identifier - Uniform Resource Identifier). Például:
Ami az azonosítót, azt tanácsolom, hogy nézd irányába UUID (univerzálisan egyedi azonosító), támogatja a legtöbb adatbázis, és ez a megközelítés segít biztosítani krosc-rendszer egyedi azonosítók. például:
Önálló üzenetét. Minden válasz tartalmazza az összes szükséges információt, hogy megfelelően tudja kezelni anélkül, hogy segítségével más források.
HATEOAS. Hipermédia mint a motor alkalmazásának államban.
Hipermédia kontrollként mechanizmus alkalmazási körülmények között.
Hipermédia - erőforrás típusú tartalom-alapú Hypertext Markup. Hypertext, ebben az összefüggésben, ahogy Fielding megítélése szerint az egyidejű információ, és az elemek kiválasztása.
„Így, hipermédia egyszerűen kiterjesztése, amelyet az jellemez, a jelenlét az információ tartalma ideiglenes linkek más tartalom a média folyam”.
kérésére a kódot. Egy opcionális eleme a szerkezet. Ez lehetővé teszi, hogy megkapja a kódot rákövetkező végrehajtása az ügyfél.
Így, ha a kérelem megfelel a követelményeknek (korlátok), a fent leírtak szerint, akkor nyugodtan nevezhetjük RESTful. A kivétel csak a kódot a kérelmet - ez a paraméter nem kötelező.
Egy jó API könnyen érthető és könnyen alkalmazható.
Alapok REST HTTP-n keresztül.
Resource - egy egyedi tárgy, elérhető egy egyedi URL-t.
Fő URL legyen nélkül érthető dokumentációt.
ez segít, hogy egyszerűsítse az API támogatását a jövőben. Egy jó lehetőség lehet egy domain név előtag:
Vannak 2 fő típusa forrás építészet REST: gyűjtemény és tétel gyűjteménye.
A gyűjtemény gyűjteménye független és önálló elemek.
Példa egy linket egy gyűjteménye felhasználók:
Element gyűjtemény felhasználó, vagy egy adott felhasználó, ebben az esetben is képviselteti magát:
Főnevek - nos, igék - rossz.
gyűjtemények nevekkel kell a lényeg (többes főnevek), és meg kell lenniük, és világos (öndokumentáló). Amikor a kutyák, meg kell egy kutya, nem csak az állatokat.
Mindegyik erőforrás a RESTful API kezeli több meghatározott minimum igék. A legtöbb esetben elegendő 4 fő ige (HTTP-módszer):
GET, PUT, DELETE - idempotens.
Idempotencia azt jelenti, hogy nem számít, hányszor nem hívja ezt a módszert - az eredmény ugyanaz lesz.
Gyűjtemény felhasználó gépek:
(HTTP Status Code) kell különböztetni két fő családja a status kódok:
4xx - probléma merül fel a felhasználói oldalon, és ő is megjavítani, közvetlenül a szükséges információk megadásával a kérést.
5xx - a probléma történt a szerver és a megoldást, a felhasználó küldhet egy kérést a támogató szolgálat.
Hibákat világosan meg kell határozni, nem csak a felhasználó tudja, mit kell tennie, hanem a könnyen kezelhető, ha a felhasználó küld, akkor a kérést, hogy megoldja a problémát.
Példa jól megírt hogy a hiba elhárítására:
HTTP Status Code: 401
Ne feledd! Írsz egy API-t a fejlesztés, mint te.
Használja a minimálisan szükséges kódot az alkalmazás állapota.
Néha elég lehet 3:
2. 400 Bad Request (érvénytelen kérelem)
3. 500 Internal Server Error (Internal Server Error)
Ha nem elég, szükség szerint kiegészített:
1. 201 Létrehozva (sikeresen létrehozva)
2. 304 Nem módosított (az adatokat nem változott)
3. 404 Not Found (nem található)
5. 403 Forbidden (hozzáférés megtagadva)
Próbálja meg értékelni az előnyeit minden tétel hozzá a felhasználó. Ne feledje, hogy számos, főleg a felesleges elemeket, megzavarhatja még a tapasztalt fejlesztők.
Bizonyos esetekben hasznos, ha egy beállítás, hogy elnyomja a hibaállapotkódot, hogy az ügyfél mindig, ha szükséges, hogy a kód: 200, például.
Ez nem a helyén, hogy adjunk a rugalmasság az API.
Versioning.
Feltétlenül szerepeljen a verziószám, akkor is, ha nem akarja, hogy a kezelőfelület - minden gyorsan változhat.
vagy lekérdezési paraméterek:
Nincs ok arra, hogy a hosszú változata a cím, helyezze őket pont: v1.03
Oldal kérdés.
Minden gyűjtemény, akármilyen kicsi, Ön szerint, nem volt adandó egy oldalon. Döntse el a méret a kibocsátás a gyűjtemény, például Content-Type: application / json «lapozás»:> Próbálj meg mindig ugyanazt a formátumot az összes alkalmazás válaszokat -, hogy megkönnyítse az élet és a magad és a kliens szoftver fejlesztők.
Ha választani néhány defolnnye értékeket «limit» paraméterek «offset», és valószínű, hogy korlátozza a maximális értéket a «határ».
Elrejti az összes komplex összetevői a kérelmet a „?”.
Ha a GET kérés van szükség, hogy különböző szűrők - tedd mögé a kérdőjel (az URL-paraméter):
Adja meg a felhasználó csak, amit akar.
Hagyja csak azokat a mezőket, hogy az ügyfél kérheti, hogy neki szüksége:
Az adatok formátuma adni.
Ne fogja vissza magát bármelyike formátumban. Tedd tetszőleges számú, például a JSON és XML. Ebben egyszerű módon nagyban egyszerűsíti a fejlesztési ügyfelek számára, és többé nem kell választani valamit egy. visszatért adatformátum lehet leírni, mint a HTTP fejlécek és lekérdező sztring:
És biztos, hogy választani néhány alapértelmezett formátum.
Ez egyike azon kevés erőforrás típusok, amelynek az a rendeltetése, hogy továbbra is egy ige. Mármint globális keresést.
Ismét különböző szűrőket alkalmazhatunk függően rendszer által használt kereső.
Néhány helyi keresés belül egy gyűjteményt, akkor lehet, hogy egy egyszerű és szűrő:
Használja, amikor csak lehetséges, a legújabb verzióját OAuth - OAuth 2.0 - Ez a rendszer jól ismert tervezők, és jól működött. Miért feltalálni a kereket?
Dokumentációt.
Ez az egyik legfontosabb szempontja a jó API-t. Bárki, aki valaha szembe az írás kliensoldali szkript, egyetért velem. Töltött órák jó dokumentáció fogja kompenzálni hosszú hónapok munkájának támogatására. A trükk egyszerű - írja világosan és tömören az összes beérkezett adatokat, és így, valamint a kinevezését módszereket. Ne feledd! Írsz a programozók. Nem szükséges, hogy leírja néhány nyilvánvaló pont. Hogy minden, hogy a status a kódok; felsorolni az összes beérkezett paraméterek írják le őket, ahol szükség van; linkek segítségével részletesebb anyagot; példák az adatokat szükség, azok leírását.
Próbálja meg választ adni a hivatkozás a kapcsolódó források, ha azt szeretné, hogy megfeleljenek az elvet HATEOAS, és felhívta RESTful. Erre akkor nagyon szereti a fejlesztők kliens programok - nem maguk előállítani ezeket a linkeket.
Most a legfontosabb dolog!
Homlokzati minta API-t.
Bármilyen API fejlesztés kell kezdeni egy részletes tanulmányt a felület. Tény, hogy az elején a kód írása a kezében legyen minden URI API részletes dokumentációt minden paraméter minden rendelkezésre álló egy adott URI módszer, mind a visszatérő állapot kódokat és adatformátum, hogy visszatérjen. Ideális esetben ez a felület már nem kell változtatni a további fejlesztés során. Ez a megközelítés nagyban megkönnyíti és felgyorsítja a munkát az alapvető API-kódot, és lehetővé teszi a párhuzamos írás kliens szoftver már a kezdeti fejlődési szakaszban.
Ne feledd! Az API kell lennie egyszerű és világos, az egyetlen módja annak, hogy a boldogság és a harmónia.
Senior Web Developer / Team Lead, Company SECL Group / Internet Sales Technologies