Praktický design REST API

Miroslav Holec       22.11.2020       Architektura       3178 zobrazení

Jedno z nejdůležitějších témat v souvislosti s vývojem REST API je design. Špatně navržené API má nepříjemné důsledky. Konzumenty nutí používat jej nestandardním způsobem a různě ohýbat nástroje, na které jsou zvyklí. Prodlužuje se doba implementace a vznikají bugy, se kterými implementátor většinou nepočítá. Chybně navržené API zkrátka hází klacky pod nohu konzumentům a vytváří tlak na nápravu. Ta není jednoduchá. API je v již produkčním provozu a jakákoliv změna navenek znamená rozbití již existujících integrací. Časté řešení a zároveň velká past je verzování API. To zvyšuje komplexitu projektů a vede buď k redundanci nebo tvorbě složitých řešení, jejichž devizou jsou neustálé bugy. Jediná cesta ven je navrhnout API co nejlépe již na začátku a následné změny provádět s určitou mírou prevence před potenciálními scénáři.

Jako RESTová API jsou dnes často mylně označovaná všechna API, která jsou založena na protokolu HTTP a přenosovém formátu JSON. Na druhou stranu REST omezení, která byla definována R. T. Fieldingem před dvěma dekádami v podstatě popisují nejen API, ale obecně mnoho běžných WWW stránek. Neexistuje jasná norma, která by rozlišovala správný a špatný návrh API. To znamená, že dobře navržené API je obvykle v gesci architekta. Ten vezme již osvědčené postupy, přileje trochu praxe a výše zmíněné prevence či specifika projektu a na základě těchto a dalších vstupů navrhne design, který s trochou štěstí odolá náporu následných požadavků.

Není složité udělat API restful, je těžké udělat API „správně“. Pojem „správné API“ je ale z logiky věci zcela vágní. Od API očekáváme dvě věci. Jednak umožnit pohodlně konzumovat data klientům a druhak kontinuálně zachovávat zpětnou kompatibilitu. Oba požadavky spolu souvisí, protože bez zpětné kompatibility velmi rychle snížíme komfort při konzumaci. Na druhou stranu zachování kompatibility může být výzva, která nás ve jménu klientského komfortu může stát nadměrné úsilí.

V případě, že API stavíme jako backend pro naše vlastní SPA aplikce, je situace snazší. Jsme totiž tvůrcem i jediným konzumentem. Můžeme si tudíž velmi jednoduše dovolit API přepsat a nasadit jeho novou verzí společně s klientskou aplikací. V případě mobilních aplikací už to není tak jednoduché, protože uživatelé mohou mít nasazené starší verze aplikací a my je nepřinutíme, aby v jeden okamžik použili verzi novou a plně funkční. I případ vlastní SPA aplikace se může rychle změnit. Co když budeme chtít v jeden okamžik data zpřístupnit dalším konzumentům? Na designu REST API zkrátka záleží vždy.

Webinář praktický design REST API

Téma mi přijde natolik zajímavé a důležité, že jsem pro něj nachystal nový webinář. Během něj chci účastníky seznámit s REST principem a více rozvést myšlenky, které jsem nastínil v tomto článku. Na scénářích z praxe vysvětlím, jak nad designem obecně uvažovat a jak hluboko se jím kdy zabývat. Ukážu také sadu praktických „návrhových vzorů“ a osvědčených postupů pro vývoj REST API, které jsem v posledních letech použil. Místo programování se budu převážnou část věnovat zejména návrhu a správné podobě endpointů a vracených struktur. Tématicky se pozastavíme i u trendu tzv. asynchronních API a chybět nebude ani pár tipů pro návrh architektury REST API v ASP.NET Core.

Registrace na webinář je možná zde.


 

hodnocení článku

0       Hodnotit mohou jen registrované uživatelé.

 

Mohlo by vás také zajímat

Jak rozšířit aplikaci o zásuvné moduly (Plug-in)

Vzhledem k zájmu v oblasti rozšíření aplikace pomocí zásuvných modulů (dynamické volání knihoven) jsem se rozhodl napsat tento krátký článek. Měl by vám pomoci pochopit základní princip a ukázat jednoduchý příklad v praxi.

Windows Presentation Foundation (WPF) - díl 2.: Architektura WPF – Dispatcher

Znát alespoň obrysy toho, jak funguje unvitř technologie, kterou využíváme je nezbytná nutnost. A právě nižší architektuře WPF se věnuje tento článek - konkrétně objektu Dispatcher.

asp mvc – from zero to hero (4), MVC architektura, view-viewmodel-controller, razor

 

 

Nový příspěvek

 

Příspěvky zaslané pod tento článek se neobjeví hned, ale až po schválení administrátorem.

                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.

Nyní zakládáte pod článkem nové diskusní vlákno.
Pokud chcete reagovat na jiný příspěvek, klikněte na tlačítko "Odpovědět" u některého diskusního příspěvku.

Nyní odpovídáte na příspěvek pod článkem. Nebo chcete raději založit nové vlákno?

 

  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

Příspěvky zaslané pod tento článek se neobjeví hned, ale až po schválení administrátorem.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback