Základy vývoje REST a RESTful API

Weboví vývojáři často mluví Zásady REST a datová architektura RESTful, je to zásadní aspekt moderního vývoje, ale někdy to může být neuvěřitelně matoucí. REST není technologie sama o sobě, ale spíše metoda vytváření API s určitými organizačními principy. Tyto zásady jsou určeny pro vývojáře a vytvořit univerzálnější prostředí pro zpracování požadavků API.

V tomto příspěvku bych rád vysvětlil RESTful vývojové postupy z ptačí perspektivy. Chci se zabývat co spíše než jak. I když se budu dotýkat obou oblastí, tento příspěvek je vytvořen pro každého, kdo se zabývá vývojem webu, ale jednoduše nemůže pochopit koncept rozhraní API REST.

REST Pro webové vývojáře

Zkratka REST znamená Reprezentativní státní převod. To může znít poněkud matoucí a vstup do wiki to zní ještě zmateněji. Terminologii je však možné zjednodušit.

REST je jen série pokyny a architektonické styly používané pro přenos dat. To je obyčejně aplikováno na webové aplikace, ale moci předávat data k softwaru také.

Zkratka API označuje aplikační programové rozhraní, které jsou metodami spojení s jinými knihovnami nebo aplikacemi. Windows má více API a Twitter má také webové rozhraní API, i když plní různé úkoly s různými cíli.

Kombinace všech RESTful API jsou API, která následují architekturu REST.

Co přesně je architektura REST?

To je místo, kde je těžké stanovit specifika. Existují však některé architektonické konstanty, například:

• Konzistence v celém API
• Existence bez státní příslušnosti, tj. žádné relace na straně serveru
• Použití Stavové kódy HTTP kde se to hodí
• Použití Koncové body adresy URL s logickou hierarchií
• Verze v URL než v hlavičkách HTTP

Nejsou žádné příliš specifické pokyny, jako je specifikace W3C HTML5, která by mohla vést k nejasnostem, a miasma nejistoty ohledně terminologie REST.

Také výše uvedený seznam by neměly být považovány za tvrdá a rychlá pravidla, i když jsou pravdivé pro většinu moderních API RESTful.

REST je a metodiku což je ideální pro HTTP data. To je důvod, proč REST stal se tak populární na webu, a proč je široce považován za nejlepší volbu pro vývoj API.

Jak to říká Vinay Sahni, “API je uživatelské rozhraní vývojáře.” Všechno by mělo být snadno použitelné a mělo by poskytovat skvělý uživatelský zážitek. Rozhraní API RESTful to mají za cíl.

Key Takeaways Pro RESTful API

Tyto tipy jsou v kontextu rozhraní API striktně pro webové aplikace. Tohle znamená tamto HTTP je požadavek, a často to znamená data API jsou hostována na externím serveru. Prozkoumejme, jak rozhraní API RESTful pracuje na straně uživatele rozhraní API.

Uživatelem rozhraní API je webový vývojář, který může vytvořit skript, který se připojuje k externímu serveru API, poté jsou potřebná data předávána přes protokol HTTP. Vývojář pak může zobrazit data na svých webových stránkách bez osobního přístupu k externímu serveru (jako tahání dat služby Twitter).

Obecně řečeno, existují čtyři příkazy bývalo přístup k rozhraním RESTful API:

1. DOSTAT pro načtení objektu
2. POŠTA pro vytvoření nového objektu
3. DÁT pro změnu nebo nahrazení objektu
4. DELETE pro odstranění objektu

Každá z těchto metod by měla být s voláním API říct serveru, co má dělat.

Drtivá většina webových rozhraní API povolit DOSTAT žádostí vytáhnout data z externího serveru. Autentizace je volitelná, ale jistě je to dobrý nápad, když povolujete potenciálně škodlivé příkazy DÁT nebo DELETE.

Nicméně, ne mnoho API RESTful dokonce jít tak daleko. Zvažte Pokéapi, který je zdarma Pokémon API databáze. Je otevřen pro veřejnost s přiměřeným omezením sazeb (omezením uživatelů na určitý počet požadavků API v určitém časovém období), ale umožňuje pouze DOSTAT pro přístup ke zdrojům. Toto může být hovorově nazýváno API.

Typy návratů jsou také důležité a měly by zachovat homogenitu pro všechny zdroje. JSON je populární návratový typ s online specifikacemi, které vysvětlují správné datové struktury.

Používají se rozhraní API RESTful podstatná jména pro objekty API, a slovesa pro provádění akcí na těchto objektech. Součástí může být i ověřování, jehož součástí může být i omezení rychlosti. Ale velmi jednoduché API může získat bez velkého znepokojení uživatelských omezení.

Přístup k prostředkům API

Veřejná rozhraní API jsou obvykle přístupné z přímých adres webových stránek. To znamená struktura URL je důležitá, a měly by být použity pouze pro požadavky API.

Některé adresy URL mohou obsahovat adresář předpony / v2 / pro aktualizovanou verzi 2 předchozího rozhraní API. To je běžné pro vývojáře, kteří nechtějí odpisovat své 1.x API, ale přesto chtějí nabídnout nejnovější strukturu.

Opravdu jsem si tento post kryl základní struktury URL a příklady z jiných služeb.

Všimněte si, že koncový bod je návratová data se změní dramaticky založený na Metoda HTTP. Například, DOSTAT načítání obsahu POŠTA vytváří nový obsah. Požadavek by mohl ukazovat na stejný koncový bod, ale výsledek by mohl být velmi odlišný.

Prohlížení příkladů online vám může pomoci pochopit koncepty jasněji. Už jsme viděli Pokeapi, ale tady jsou další příklady reálného API sledovat:

• Reddit API
• GitHub API
• Flickr API
• Pinterest API

Vytváření vlastních rozhraní API

Proces tvorby vlastního API by neměl být brát na lehkou váhu, ale také není tak složitý, jak si myslíte. Trvá to porozumění návrhovým vzorům API a osvědčeným postupům vybudovat něco reálné.

Každé API musí připojení k serveru vrátit data nějakého druhu. Nejen, že k tomu musíte napsat kód, ale také potřebujete formátovat data návratu. Další potenciální požadavky zahrnují autentizace a omezení rychlosti, takže budování API rozhodně není pro slabé srdce.

Ale podívejme se základní principy architektury API.

Sestavte koncové body

Jedním z aspektů vývoje API je budov. Když vytváření zdrojů chcete použít podstatná jména, nikoli slovesa. To znamená, že data API by měla vracet osobu, místo nebo věc, nejčastěji je to věc se specifickými atributy (například tweet a všechna jeho metadata).

To může být obtížné učit se jmenná jména, ale toto je klíčový aspekt vývoje API. Zjednodušení je nejlepší, kdykoli je to možné.

Velká debata je singulární vs. množné číslo podstatná jména. Pokud jste vytvořili rozhraní API služby Twitter, můžete mít nejprve skupinu objektů (tj. Tweet), potom druhou položku objektu (tj. Tweet ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

V tomto případě bych tvrdil, že singulární forma vypadá lépe. To platí zejména při vrácení pouze jednoho prostředku. Neexistuje však zdokumentovaná 100% správná odpověď.

Nastavit typ návratu

Další úvaha je data typu návratu. Většina uživatelů webu očekává obsah JSON, takže je to pravděpodobně nejlepší volba. XML je další volba, pokud chcete nabídnout obojí. JSON je však základním typem návratu API mezi webovými vývojáři.

Je to mnohem více, co jde do vývoje API, takže doporučuji hrát s API nejdříve. Tímto způsobem můžete vidět, jak ostatní vývojáři vytvářejí rozhraní API, a doufejme, že se seznámíte s typickými požadavky.

Pokud právě začínáte, zvažte prosím skimming těchto dev tutoriálů:

• REST API Tutorial Site
• Zápis jednoduchého rozhraní API REST
• Vytvoření webové služby RESTful

Další zdroje

Nejlepší způsob, jak se naučit vývoj webových aplikací, je prostřednictvím praxe. Udělená teorie je vždy stojí za to studovat, protože to umožňuje konverzovat s vývojáři a pochopit, jak věci fungují.

Dobré místo pro začátek s vývojem rozhraní API je však spojení s jinými API První. Naučte se základy připojení na straně klienta a odtud můžete přejít na vývoj API na straně serveru vytvořením vlastního rozhraní API od nuly.

Pokud je to váš cíl, zvažte prosím následující zdroje, které vám pomohou s cestou.

Knihy

• REST API Návrh pravidla
• RESTful Web API
• RESTful Web Services Cookbook
• Nerušené REST: Průvodce navrhováním Perfect API

Články

• Průvodce začátečník k HTTP a REST
• Vytvoření rozhraní RESTful API
• RESTful Resource Naming Guide
• Vytvoření rozhraní API REST pomocí zásobníku MEAN