REST je zkratka pro reprezentativní státní převod, termín vytvořený Roy Fieldingem v roce 2000. Jedná se o styl architektury pro navrhování volně propojených aplikací přes HTTP, který se často používá při vývoji webových služeb. REST nevynucuje žádné pravidlo týkající se toho, jak by mělo být implementováno na nižší úrovni, pouze dal pokyny pro návrh na vysoké úrovni a nechal vás přemýšlet o své vlastní implementaci.
ve svém posledním zaměstnání jsem navrhl RESTful API pro významnou telekomunikační společnost na dva dobré roky. V tomto příspěvku, budu sdílet své myšlenky na rozdíl od standardních konstrukčních postupů. Možná se mnou nesouhlasíte v několika bodech, a to je naprosto v pořádku. Budu rád diskutovat o cokoliv od vás s otevřenou myslí.
začněme se standardními designovými specifickými věcmi, abychom objasnili, co „Roy Fielding“ chce, abychom postavili. Pak budeme diskutovat o mých myšlenkách, které budou více směřovat k jemnějším bodům, zatímco budete navrhovat své RESTful API.
architektonická omezení
REST definuje 6 architektonických omezení, která dělají jakoukoli webovou službu-skutečné RESTful API.
- Jednotné rozhraní
- Klient–server
- bez státní Příslušnosti,
- Cacheable
- Vrstvený systém
- Kód na vyžádání (volitelné)
Jednotné rozhraní
Jako omezení sám název vztahuje, MUSÍTE se rozhodnout, Api rozhraní pro zdroje uvnitř systému, které jsou vystaveny API spotřebitele a dodržovat nábožensky. Zdroj v systému by měl mít pouze jedno logické URI, a to by mělo poskytnout způsob, jak načíst související nebo další data. Vždy je lepší synonymizovat zdroj s webovou stránkou.
žádný jednotlivý zdroj by neměl být příliš velký a měl by obsahovat vše, co je v jeho reprezentaci. Kdykoli je to relevantní, zdroj by měl obsahovat odkazy (HATEOAS) ukazující na relativní URI pro načtení souvisejících informací.
Také zastoupení zdrojů v systému by měl dodržovat zvláštní pokyny, jako jsou konvence, odkaz formátů nebo formátu dat (XML nebo JSON).
všechny zdroje by měly být přístupné prostřednictvím společného přístupu, jako je HTTP GET a podobně upraveny pomocí konzistentního přístupu.
Toto omezení v podstatě znamená, že klientská aplikace a aplikační server MUSÍ být schopen vyvíjet samostatně bez závislosti na ostatních. Klient by měl znát pouze zdroje Uri, a to je vše. Dnes je to standardní praxe ve vývoji webových aplikací, takže z VAŠÍ strany není vyžadováno nic fantastického. Jen tak dál.
bez státní příslušnosti
Roy fielding se inspiroval HTTP, takže se odráží v tomto omezení. Proveďte všechny interakce klient-server bez státní příslušnosti. Server neukládá nic o nejnovějším požadavku HTTP, který klient provedl. Každý požadavek bude považovat za nový. Žádné sezení, žádná historie.
Pokud aplikace klienta musí být stavové aplikace pro koncové uživatele, kde uživatel přihlásí jednou a dělat jiné povolené operace po tom, pak každý požadavek od klienta by měla obsahovat všechny informace nezbytné pro doručení žádosti, včetně ověření a autorizace detaily.
Cacheable
v dnešním světě je ukládání dat a odpovědí do mezipaměti nanejvýš důležité, kdekoli jsou použitelné / možné. Webová stránka, kterou zde čtete, je také verzí HTML stránky v mezipaměti. Ukládání do mezipaměti přináší zlepšení výkonu na straně klienta a lepší prostor pro škálovatelnost serveru, protože zatížení se snížilo.
v REST se ukládání do mezipaměti použije na zdroje, pokud je to vhodné, a pak se tyto zdroje musí prohlásit za cacheable. Ukládání do mezipaměti lze implementovat na Serveru nebo na straně klienta.
ZBYTEK umožňuje použití vícevrstvé architektury systému, kde nasazení Api na server, a ukládat data na server B a ověření požadavků na Server C, například. Klient obvykle nemůže zjistit, zda je připojen přímo ke koncovému serveru nebo zprostředkovateli.
kód na vyžádání (volitelné)
toto omezení je volitelné. Většinu času budete posílat statické reprezentace zdrojů ve formě XML nebo JSON. Ale když potřebujete, máte možnost return executable code podporovat část vaší aplikace, např., klienti mohou volat vaše API získat UI widget Vykreslování kód. Je to povoleno.
Všimněte si, že všechna výše uvedená omezení jsou nejvíce úzce souvisí s WWW (web). Pomocí RESTful API můžete s webovými službami dělat to samé, co děláte s webovými stránkami.