Sdílet prostřednictvím

Osvědčené postupy pro návrh webového rozhraní API RESTful

Implementace webového rozhraní RESTful je webové rozhraní API, které využívá architekturu REST (Representational State Transfer) k dosažení bezstavového volně svázaného rozhraní mezi klientem a službou. Webové rozhraní API, které je RESTful, podporuje standardní protokol HTTP pro provádění operací s prostředky a vracení reprezentací prostředků, které obsahují odkazy hypermedia a stavové kódy operací HTTP.

Webové rozhraní API RESTful by mělo odpovídat následujícím principům:

  • Nezávislost platformy, což znamená, že klienti mohou volat webové rozhraní API bez ohledu na interní implementaci. K dosažení nezávislosti platformy webové rozhraní API používá protokol HTTP jako standardní protokol, poskytuje jasnou dokumentaci a podporuje známý formát výměny dat, jako je JSON nebo XML.

  • Volné spojení, což znamená, že klient a webová služba se mohou nezávisle vyvíjet. Klient nemusí znát interní implementaci webové služby a webová služba nemusí znát interní implementaci klienta. Pokud chcete dosáhnout volného párování ve webovém rozhraní RESTful API, použijte pouze standardní protokoly a implementujte mechanismus, který klientovi a webové službě umožňuje odsouhlasit formát dat, který se má vyměňovat.

Tento článek popisuje osvědčené postupy pro návrh webových rozhraní RESTful API. Zabývá se také běžnými vzory návrhu a aspekty vytváření webových rozhraní API, které jsou snadno pochopitelné, flexibilní a udržovatelné.

Koncepty návrhu webového rozhraní API RESTful

Pokud chcete implementovat webové rozhraní RESTful API, musíte porozumět následujícím konceptům.

  • Identifikátor URI (Uniform Resource Identifier): Rozhraní REST API jsou navržená kolem prostředků, což jsou jakýkoli druh objektu, dat nebo služby, ke kterým má klient přístup. Každý prostředek je reprezentován identifikátorem URI, který jednoznačně identifikuje daný prostředek. Například identifikátor URI pro konkrétní objednávku zákazníka může být:

    https://api.contoso.com/orders/1

  • Reprezentace prostředků definuje, jak se prostředek identifikovaný jeho identifikátorem URI kóduje a přenáší přes protokol HTTP v určitém formátu, například XML nebo JSON. Klienti, kteří chtějí načíst konkrétní prostředek, musí v požadavku na rozhraní API použít identifikátor URI prostředku. Rozhraní API vrátí reprezentaci zdrojů dat, které URI označuje. Klient může například vytvořit požadavek GET na identifikátor URI https://api.contoso.com/orders/1 a obdržet následující text JSON:

    {"orderId":1,"orderValue":99.9,"productId":1,"quantity":1}

  • Jednotné rozhraní je způsob, jakým rozhraní RESTful API dosahuje volné vazby mezi implementacemi klientů a služeb. Pro rozhraní REST API, která jsou založená na protokolu HTTP, jednotné rozhraní zahrnuje použití standardních příkazů HTTP k provádění operací, jako je GET, POST, PUT, PATCH a DELETE na prostředcích.

  • Model bezstavového požadavku: Rozhraní RESTful API používají bezstavový model požadavků, což znamená, že požadavky HTTP jsou nezávislé a můžou nastat v libovolném pořadí. Z tohoto důvodu není možné uchovávat přechodné informace o stavu mezi požadavky. Jediné místo, kde jsou uložené informace, je v samotných prostředcích, a každý požadavek by měl být atomickou operací. Bezstavový model žádosti podporuje vysokou škálovatelnost, protože nemusí uchovávat žádné spřažení mezi klienty a konkrétními servery. Bezstavový model ale může také omezit škálovatelnost kvůli problémům se škálovatelností back-endového úložiště webových služeb. Další informace o strategiích horizontálního navýšení kapacity úložiště dat najdete v tématu Dělení dat.

  • Hypermediální odkazy: Rozhraní REST API mohou být ovládána hypermediálními odkazy, které jsou obsaženy v každé reprezentaci prostředků. Například následující blok kódu zobrazuje reprezentaci objednávky ve formátu JSON. Obsahuje odkazy na získání nebo aktualizaci zákazníka přidruženého k objednávce.

    {
  "orderID":3,
  "productID":2,
  "quantity":4,
  "orderValue":16.60,
  "links": [
    {"rel":"product","href":"https://api.contoso.com/customers/3", "action":"GET" },
    {"rel":"product","href":"https://api.contoso.com/customers/3", "action":"PUT" }
  ]
}

Definování identifikátorů URI prostředků webového rozhraní API RESTful

Webové rozhraní API RESTful je uspořádané kolem prostředků. Chcete-li uspořádat návrh API podle prostředků, definujte URI zdrojů mapujících obchodní entity. Pokud je to možné, používejte identifikátory URI prostředků založené na podstatných jménech (prostředky) a nikoli slovesech (operace s prostředky).

Například v systému elektronického obchodování můžou být primárními obchodními entitami zákazníci a objednávky. Pokud chcete vytvořit objednávku, klient odešle informace o objednávce v požadavku HTTP POST na adresu URI. Odpověď HTTP na požadavek označuje, jestli vytvoření objednávky proběhlo úspěšně.

Identifikátor URI pro vytvoření prostředku objednávky může vypadat nějak takto:

https://api.contoso.com/orders // Good

Nepoužívejte slovesa v identifikátorech URI k reprezentaci operací. Například následující identifikátor URI se nedoporučuje:

https://api.contoso.com/create-order // Avoid

Entity se často seskupují do kolekcí, jako jsou zákazníci nebo objednávky. Kolekce je samostatným prostředkem nezávislým na položkách, které jsou v ní obsaženy, proto by měla mít vlastní identifikátor URI. Například následující identifikátor URI může představovat kolekci objednávek:

https://api.contoso.com/orders

Jakmile klient načte kolekci, může vytvořit požadavek GET na identifikátor URI každé položky. Pokud například chcete získat informace o konkrétní objednávce, klient provede na URI https://api.contoso.com/orders/1 požadavek HTTP GET, aby obdržel následující JSON tělo jako reprezentaci interních dat objednávky.

{"orderId":1,"orderValue":99.9,"productId":1,"quantity":1}

Zásady pojmenovávání URI prostředků

Při návrhu webového rozhraní RESTful API je důležité, abyste pro prostředky používali správné zásady vytváření názvů a relací:

  • Při pojmenovávání prostředků použijte podstatná jména. K reprezentaci zdrojů použijte podstatná jména. Například použijte /orders místo /create-order. Metody HTTP GET, POST, PUT, PATCH a DELETE již naznačují slovní akci.

  • K pojmenování identifikátorů URI kolekce použijte podstatná jména v množném čísle. Obecně je vhodné použít množné číslo pro URI, které odkazují na kolekce. Je vhodné uspořádat identifikátory URI pro kolekce a položky do hierarchie. Je to například /customers cesta k kolekci zákazníka a /customers/5 je to cesta k zákazníkovi s ID, které se rovná 5. Tento přístup pomáhá udržovat webové rozhraní API intuitivní. Mnoho architektur webového rozhraní API také může směrovat požadavky na základě parametrizovaných cest URI, takže můžete definovat trasu pro cestu /customers/{id}.

  • Zvažte vztahy mezi různými typy prostředků a způsob, jakým můžete tato přidružení vystavit. Například /customers/5/orders může představovat všechny objednávky pro zákazníka 5. Ke vztahu můžete přistupovat také v opačném směru tím, že zobrazíte vztah od objednávky k zákazníkovi. V tomto scénáři může být identifikátor URI /orders/99/customer. Rozšíření tohoto modelu však může být příliš náročné na implementaci. Lepším přístupem je zahrnout odkazy do textu zprávy odpovědi HTTP, aby klienti měli snadný přístup k souvisejícím prostředkům. Pomocí hypertextu jako stroje stavu aplikace (HATEOAS) můžete povolit navigaci na související prostředky , které tento mechanismus podrobněji popisují.

  • Udržujte vztahy jednoduché a flexibilní. Ve složitějších systémech můžete mít sklon poskytovat identifikátory URI, které klientovi umožňují procházet několik úrovní relací, jako například je /customers/1/orders/99/products. Tuto úroveň složitosti ale může být obtížné udržovat a je nepružná, pokud se vztahy mezi prostředky v budoucnu změní. Místo toho zkuste zachovat identifikátory URI relativně jednoduché. Jakmile má aplikace odkaz na prostředek, měli byste být schopni použít tento odkaz k vyhledání položek souvisejících s tímto prostředkem. Předchozí dotaz můžete nahradit identifikátorem URI /customers/1/orders, abyste našli všechny objednávky pro zákazníka 1, a poté použít /orders/99/products k nalezení produktů v této objednávce.

    Návod

    Vyhněte se vyžadování identifikátorů URI prostředků, které jsou složitější než kolekce/položka/kolekce.

  • Vyvarujte se používání velkého množství malých zdrojů. Všechny webové požadavky zatěžují webový server. Čím více požadavků, tím větší je zatížení. Webová rozhraní API, která zpřístupňují velký počet malých prostředků, se označují jako komunikativní webová API. Snažte se těmto rozhraním API zabránit, protože vyžadují, aby klientská aplikace odesílala více požadavků, aby našla všechna data, která vyžaduje. Místo toho zvažte denormalizaci dat a kombinování souvisejících informací do větších prostředků, které je možné načíst prostřednictvím jednoho požadavku. Stále ale musíte tento přístup vyvážit s režií při načítání dat, která klient nepotřebuje. Načítání velkých objektů může zvýšit latenci požadavku a vyžadovat větší náklady na šířku pásma. Další informace o těchto výkonnostních antipatternech naleznete v tématech Chatty I/O a Extraneous Fetching.

  • Vyhněte se vytváření rozhraní API, která zrcadlí interní strukturu databáze. Účelem REST je modelovat obchodní entity a operace, které může aplikace s těmito entitami provádět. Klient by neměl být vystaven interní implementaci. Pokud jsou například vaše data uložená v relační databázi, webové rozhraní API nemusí vystavit každou tabulku jako kolekci prostředků. Tento přístup zvyšuje prostor pro útok a může vést k úniku dat. Místo toho si webové rozhraní API představte jako abstrakci databáze. V případě potřeby vytvořte mezi databází a webovým rozhraním API vrstvu mapování. Tato vrstva zajišťuje izolaci klientských aplikací od změn základního schématu databáze.

Návod

Nemusí být možné mapovat každou operaci implementovanou webovým rozhraním API na konkrétní prostředek. Tyto scénáře bez zdroje můžete zpracovat prostřednictvím požadavků HTTP, které volají funkci a vrací výsledky jako zprávu odpovědi HTTP.

Například webové rozhraní API, které implementuje jednoduché operace kalkulačky, jako je sčítání a odčítání, může poskytovat identifikátory URI, které tyto operace zveřejňují jako pseudonabídky, a pomocí řetězce dotazu zadat požadované parametry. Požadavek GET na identifikátor URI /add?operand1=99&operand2=1 vrátí zprávu odpovědi s textem obsahujícím hodnotu 100.

Tyto formy identifikátorů URI byste však měli používat střídmě.

Definování metod webového rozhraní API RESTful

Metody webového rozhraní API RESTful odpovídají metodám požadavků a typům médií definovaným protokolem HTTP. Tato část popisuje nejběžnější metody požadavků a typy médií používané ve webových rozhraních RESTful API.

Metody požadavků HTTP

Protokol HTTP definuje mnoho metod požadavků, které označují akci, kterou chcete provést u prostředku. Nejběžnějšími metodami používanými ve webových rozhraních RESTful jsou GET, POST, PUT, PATCH a DELETE. Každá metoda odpovídá konkrétní operaci. Při návrhu webového rozhraní API RESTful použijte tyto metody způsobem, který je konzistentní s definicí protokolu, prostředkem, ke kterému se přistupuje, a akcí, která se provádí.

Je důležité si uvědomit, že účinek konkrétní metody požadavku by měl záviset na tom, jestli je prostředek kolekce nebo jednotlivé položky. Následující tabulka obsahuje některé konvence, které většina implementací RESTful používá.

Důležité

Následující tabulka používá příklad entity elektronického obchodování customer . Webové rozhraní API nemusí implementovat všechny metody požadavků. Metody, které implementuje, závisí na konkrétním scénáři.

zdroj POST ZÍSKAT UMÍSTIT VYMAZAT
/zákazníci Vytvoření nového zákazníka Načtení všech zákazníků Hromadná aktualizace zákazníků Odebrání všech zákazníků
/customers/1 Chyba Načtení podrobností pro zákazníka 1 Aktualizace podrobností o zákazníkovi 1, pokud existuje Odstranit zákazníka 1
/zákazníci/1/objednávky Vytvoření nové objednávky pro zákazníka 1 Načtení všech objednávek pro zákazníka 1 Hromadná aktualizace objednávek pro zákazníka 1 Odstraňte všechny objednávky zákazníka 1

Požadavky GET

Požadavek GET získá reprezentaci prostředku u zadaného URI. Text zprávy odpovědi obsahuje podrobnosti požadovaného prostředku.

Požadavek GET by měl vrátit jeden z následujících stavových kódů HTTP:

Stavový kód HTTP Důvod
200 (OK) Metoda úspěšně vrátila prostředek.
204 (bez obsahu) Tělo odpovědi neobsahuje žádný obsah, například když požadavek hledání nevrátí žádné shody v odpovědi HTTP.
404 (Nenalezena) Požadovaný prostředek nebyl nalezen.

Žádosti POST

Požadavek POST má za úkol vytvořit prostředek. Server přiřadí identifikátor URI pro nový prostředek a vrátí tento identifikátor URI klientovi.

Důležité

U požadavků POST by se klient neměl pokoušet vytvořit vlastní identifikátor URI. Klient by měl odeslat požadavek k URI kolekce a server by měl novému prostředku přiřadit identifikátor URI. Pokud se klient pokusí vytvořit vlastní identifikátor URI a vydá požadavek POST na konkrétní identifikátor URI, server vrátí stavový kód HTTP 400 (CHYBNÝ POŽADAVEK), který indikuje, že metoda není podporovaná.

V modelu RESTful se požadavky POST používají k přidání nového prostředku do kolekce, kterou identifikátor URI identifikuje. Požadavek POST se ale dá použít také k odeslání dat ke zpracování do existujícího prostředku bez vytvoření nového prostředku.

Požadavek POST by měl vrátit jeden z následujících stavových kódů HTTP:

Stavový kód HTTP Důvod
200 (OK) Metoda provedla určité zpracování, ale nevytvoří nový prostředek. Výsledek operace může být součástí textu odpovědi.
201 (vytvořeno) Prostředek byl úspěšně vytvořen. URI nového prostředku je zahrnuto v hlavičce Location odpovědi. Tělo odpovědi obsahuje reprezentaci prostředku.
204 (bez obsahu) Text odpovědi neobsahuje žádný obsah.
400 (Špatný požadavek) Klient do požadavku umístil neplatná data. Tělo odpovědi může obsahovat další informace o chybě nebo odkaz na identifikátor URI, který poskytuje další podrobnosti.
405 (metoda není povolena) Klient se pokusil odeslat požadavek POST na identifikátor URI, který nepodporuje požadavky POST.

Požadavek PUT

Požadavek PUT by měl aktualizovat existující prostředek, pokud existuje, nebo v některých případech vytvořit nový prostředek, pokud neexistuje. Vytvoření požadavku PUT:

  1. Klient určuje identifikátor URI prostředku a obsahuje text požadavku, který obsahuje úplnou reprezentaci prostředku.
  2. Klient odešle požadavek.
  3. Pokud prostředek s tímto identifikátorem URI již existuje, bude nahrazen. V opačném případě se vytvoří nový prostředek, pokud ho trasa podporuje.

Metody PUT se použijí u prostředků, které jsou jednotlivé položky, například konkrétní zákazník, místo kolekcí. Server může podporovat aktualizace, ale ne vytvoření prostřednictvím PUT. Zda podporovat vytváření prostřednictvím PUT závisí na tom, zda může klient smysluplně a spolehlivě přiřadit identifikátor URI k prostředku dříve, než existuje. Pokud to nejde, použijte POST k vytvoření prostředků a nechte server přiřadit URI. Pak pomocí příkazu PUT nebo PATCH aktualizujte identifikátor URI.

Důležité

Požadavky PUT musí být idempotentní, což znamená, že odeslání stejného požadavku několikrát vede k tomu, že tentýž prostředek je vždy upraven stejnými hodnotami. Pokud klient znovu odešle požadavek PUT, výsledky by měly zůstat beze změny. Naproti tomu není zaručeno, že požadavky POST a PATCH jsou idempotentní.

Požadavek PUT by měl vrátit jeden z následujících stavových kódů HTTP:

Stavový kód HTTP Důvod
200 (OK) Zdroj byl úspěšně aktualizován.
201 (vytvořeno) Prostředek byl úspěšně vytvořen. Tělo odpovědi může obsahovat reprezentaci prostředku.
204 (bez obsahu) Prostředek byl úspěšně aktualizován, ale text odpovědi neobsahuje žádný obsah.
409 (konflikt) Požadavek nelze dokončit kvůli konfliktu s aktuálním stavem prostředku.

Návod

Zvažte implementaci hromadných operací HTTP PUT, které můžou dávkově aktualizovat více prostředků v kolekci. Požadavek PUT by měl určovat identifikátor URI kolekce. Text požadavku by měl obsahovat podrobnosti o prostředcích, které se mají upravit. Tento přístup může pomoct snížit chattivost a zlepšit výkon.

Požadavky PATCH

Požadavek PATCH provádí částečnou aktualizaci existujícího prostředku. Klient určuje identifikátor URI prostředku. Tělo požadavku určuje sadu změn, které se mají na prostředek použít. Tato metoda může být efektivnější než použití požadavků PUT, protože klient odesílá změny pouze a ne celou reprezentaci prostředku. Patch může také vytvořit nový prostředek zadáním sady aktualizací prázdného nebo nulového prostředku, pokud server tuto akci podporuje.

Při požadavku PATCH klient odešle sadu aktualizací k existujícímu prostředku ve formě patchovacího dokumentu. Server zpracuje dokument opravy k provedení aktualizace. Dokument opravy určuje pouze sadu změn, které se mají použít místo popisu celého prostředku. Specifikace metody PATCH RFC 5789 nedefinuje konkrétní formát pro dokumenty oprav. Formát musí být odvozen z typu média v požadavku.

JSON je jedním z nejběžnějších formátů dat pro webová rozhraní API. Hlavní formáty oprav JSON jsou JSON patch a JSON merge patch.

Sloučovací patch JSON je jednodušší než patch JSON. Dokument opravy má stejnou strukturu jako původní prostředek JSON, ale obsahuje pouze podmnožinu polí, která by se měla změnit nebo přidat. Kromě toho lze pole odstranit zadáním null hodnoty pole v dokumentu opravy. Tato specifikace znamená, že slučovací záplata není vhodná, pokud původní prostředek může mít explicitní hodnoty typu null.

Předpokládejme například, že původní prostředek má následující reprezentaci JSON:

{
    "name":"gizmo",
    "category":"widgets",
    "color":"blue",
    "price":10
}

Tady je možná oprava sloučení JSON pro tento prostředek:

{
    "price":12,
    "color":null,
    "size":"small"
}

Tato oprava slučování informuje server o aktualizaci price, odstranění color a přidání size. Hodnoty pro name a category nejsou změněny. Další informace o opravě sloučení JSON najdete v dokumentu RFC 7396. Typ média pro opravu sloučení JSON je application/merge-patch+json.

Oprava sloučení není vhodná, pokud původní prostředek může obsahovat explicitní hodnoty null z důvodu zvláštního významu null v dokumentu opravy. Dokument opravy také neurčuje pořadí, ve kterém má server aktualizace použít. Záleží na tom, jestli na pořadí záleží v závislosti na datech a doméně. Oprava JSON definovaná v DOKUMENTU RFC 6902 je flexibilnější, protože určuje změny v posloupnosti operací, které se mají použít, včetně přidání, odebrání, nahrazení, kopírování a testování pro ověření hodnot. Typ média pro opravu JSON je application/json-patch+json.

Požadavek PATCH by měl vrátit jeden z následujících stavových kódů HTTP:

Stavový kód HTTP Důvod
200 (OK) Zdroj byl úspěšně aktualizován.
400 (Špatný požadavek) Poškozený dokument opravy
409 (konflikt) Dokument opravy je platný, ale změny nelze použít u prostředku v aktuálním stavu.
415 (nepodporovaný typ média) Formát dokumentu opravy není podporován.

Žádosti DELETE

Požadavek DELETE odstraní prostředek na zadané URI. Požadavek DELETE by měl vrátit jeden z následujících stavových kódů HTTP:

Stavový kód HTTP Důvod
204 (BEZ OBSAHU) Prostředek byl úspěšně odstraněn. Proces byl úspěšně zpracován a tělo odpovědi neobsahuje žádné další informace.
404 (NENALEZENA) Prostředek neexistuje.

Typy MIME prostředků

Reprezentace prostředků je způsob, jakým je prostředek identifikovaný identifikátorem URI kódovaný a přenášený přes protokol HTTP v určitém formátu, například XML nebo JSON. Klienti, kteří chtějí načíst konkrétní prostředek, musí v požadavku na rozhraní API použít URI. Rozhraní API reaguje tím, že vrátí reprezentaci zdrojů dat označených identifikátorem URI.

V protokolu HTTP jsou formáty reprezentace prostředků určeny pomocí typů médií, označovaných také jako typy MIME. Pro nebinární data podporuje většina webových rozhraní API JSON (typ média = application/json) a případně XML (typ média = application/xml).

Hlavička Content-Type v požadavku nebo odpovědi určuje formát reprezentace prostředků. Následující příklad ukazuje požadavek POST, který obsahuje data JSON:

POST https://api.contoso.com/orders
Content-Type: application/json; charset=utf-8
Content-Length: 57

{"Id":1,"Name":"Gizmo","Category":"Widgets","Price":1.99}

Pokud server nepodporuje typ média, měl by vrátit stavový kód HTTP 415 (nepodporovaný typ média).

Požadavek klienta může obsahovat hlavičku Accept, která obsahuje seznam typů médií, které klient přijme ze serveru ve zprávě odpovědi. Například:

GET https://api.contoso.com/orders/2
Accept: application/json, application/xml

Pokud server nemůže odpovídat žádnému z uvedených typů médií, měl by vrátit stavový kód HTTP 406 (Není přijatelný).

Implementace asynchronních metod

Někdy může metoda POST, PUT, PATCH nebo DELETE vyžadovat zpracování, které nějakou dobu trvá. Pokud před odesláním odpovědi klientovi počkáte na dokončení, může to způsobit nepřijatelnou latenci. V tomto scénáři zvažte udělat metodu asynchronní. Asynchronní metoda by měla vrátit stavový kód HTTP 202 (Accepted), který indikuje, že požadavek byl přijat ke zpracování, ale není úplný.

Zpřístupněte koncový bod, který vrací stav asynchronního požadavku, aby klient mohl monitorovat stav pravidelným dotazováním na koncový bod stavu. Do hlavičky Location odpovědi 202 zahrňte identifikátor URI koncového bodu stavu. Například:

HTTP/1.1 202 Accepted
Location: /api/status/12345

Pokud klient odešle požadavek GET do tohoto koncového bodu, odpověď by měla obsahovat aktuální stav požadavku. Volitelně může obsahovat odhadovanou dobu dokončení nebo odkaz na zrušení operace.

HTTP/1.1 200 OK
Content-Type: application/json

{
    "status":"In progress",
    "link": { "rel":"cancel", "method":"delete", "href":"/api/status/12345" }
}

Pokud asynchronní operace vytvoří nový prostředek, koncový bod stavu by měl po dokončení operace vrátit stavový kód 303 (viz ostatní). Do odpovědi 303 zahrňte hlavičku Location, která poskytuje identifikátor URI nového prostředku:

HTTP/1.1 303 See Other
Location: /api/orders/12345

Další informace naleznete v tématu Poskytnutí asynchronní podpory pro dlouhotrvající požadavky a asynchronní Request-Reply vzor.

Implementace stránkování a filtrování dat

Pokud chcete optimalizovat načítání dat a snížit velikost datové části, implementujte do návrhu rozhraní API filtrování na základě stránkování dat a dotazování. Tyto techniky umožňují klientům požadovat pouze podmnožinu dat, která potřebují, což může zlepšit výkon a snížit využití šířky pásma.

  • Stránkování rozděluje velké datové sady na menší, dobře ovladatelné bloky. Pomocí parametrů limit dotazu zadejte počet položek, které se mají vrátit, a offset zadejte výchozí bod. Nezapomeňte také poskytnout smysluplné výchozí hodnoty pro limit a offset, například limit=25 a offset=0. Například:

    GET /orders?limit=25&offset=50

    • limit: Určuje maximální počet položek, které se mají vrátit.

      Návod

      Pokud chcete zabránit útokům na dostupnost služby, zvažte uložení horního limitu počtu vrácených položek. Pokud například vaše služba nastaví max-limit=25a klient požádá limit=1000, může vaše služba v závislosti na dokumentaci k rozhraní API vrátit 25 položek nebo chybu BAD-REQUEST HTTP.

    • offset: Určuje počáteční index dat.

  • Filtrování umožňuje klientům upřesnit datovou sadu použitím podmínek. Rozhraní API umožňuje klientovi předat filtr v řetězci dotazu identifikátoru URI:

    GET /orders?minCost=100&status=shipped
    • minCost: Filtruje objednávky, které mají minimální cenu 100.
    • status: Filtruje objednávky, které mají konkrétní stav.

Zvažte následující osvědčené postupy:

  • Řazení umožňuje klientům řadit data pomocí parametru, jako je sortsort=price.

    Důležité

    Přístup k řazení může mít negativní vliv na ukládání do mezipaměti, protože parametry řetězce dotazu tvoří součást identifikátoru prostředku, který mnoho implementací mezipaměti používá jako klíč k datům uloženým v mezipaměti.

  • Výběr pole pro projekce definované klientem umožňuje klientům zadat pouze pole, která potřebují, pomocí parametru, jako je fieldsfields=id,name. Můžete například použít parametr řetězce dotazu, který přijímá seznam polí oddělených čárkami, například /orders?fields=ProductID,Quantity.

Vaše rozhraní API musí ověřit požadovaná pole, aby zajistilo, že k nim má klient povolený přístup, a nezpřístupní pole, která nejsou normálně dostupná prostřednictvím rozhraní API.

Podporovat částečné odpovědi

Některé prostředky obsahují velká binární pole, například soubory nebo obrázky. Pokud chcete překonat problémy způsobené nespolehlivými a přerušovanými připojeními a zlepšit dobu odezvy, zvažte podporu částečného načítání velkých binárních prostředků.

Pro podporu částečných odpovědí by webové rozhraní API mělo podporovat hlavičku Accept-Ranges pro požadavky GET pro velké prostředky. Tato hlavička označuje, že operace GET podporuje částečné požadavky. Aplikace klienta může odesílat GET požadavky, které vracejí podmnožinu prostředku určenou jako rozsah bajtů.

Zvažte také implementaci požadavků HTTP HEAD pro tyto prostředky. Požadavek HEAD je podobný požadavku GET s tím rozdílem, že vrací pouze hlavičky HTTP popisují prostředek s prázdným textem zprávy. Klientská aplikace může vydat požadavek HEAD, který určí, jestli se má prostředek načíst pomocí částečných požadavků GET. Například:

HEAD https://api.contoso.com/products/10?fields=productImage

Tady je příklad zprávy s odpovědí:

HTTP/1.1 200 OK

Accept-Ranges: bytes
Content-Type: image/jpeg
Content-Length: 4580

Hlavička Content-Length poskytuje celkovou velikost prostředku a hlavička Accept-Ranges označuje, že odpovídající operace GET podporuje částečné výsledky. Klientská aplikace může tyto informace použít k načtení image v menších blocích. První požadavek načte prvních 2 500 bajtů pomocí hlavičky Rozsah:

GET https://api.contoso.com/products/10?fields=productImage
Range: bytes=0-2499

Zpráva odpovědi označuje, že tato odpověď je částečná vrácením stavového kódu HTTP 206. Hlavička Content-Length určuje skutečný počet bajtů vrácených v textu zprávy, nikoli velikost prostředku. Hlavička Content-Range označuje, která část prostředku se vrátí (bajty 0–2499 z 4580):

HTTP/1.1 206 Partial Content

Accept-Ranges: bytes
Content-Type: image/jpeg
Content-Length: 2500
Content-Range: bytes 0-2499/4580

[...]

Následný požadavek z klientské aplikace může načíst zbytek prostředku.

Implementujte HATEOAS

Jedním z hlavních důvodů použití REST je schopnost procházet celou sadu prostředků bez předchozí znalosti schématu URI. Každý požadavek HTTP GET by měl vrátit informace potřebné k vyhledání prostředků souvisejících přímo s požadovaným objektem prostřednictvím hypertextových odkazů zahrnutých v odpovědi. Žádost by měla být také doprovázena informacemi, které popisují operace dostupné pro každý z těchto prostředků. Tento princip se označuje jako HATEOAS nebo Hypertext jako modul stavu aplikace. Systém je v podstatě konečný stavový počítač a odpověď na každý požadavek obsahuje informace potřebné k přechodu z jednoho stavu do druhého. Žádné další informace by neměly být nutné.

Poznámka:

Neexistují žádné standardy pro obecné účely, které definují, jak modelovat princip HATEOAS. Příklady v této části ilustrují jedno možné proprietární řešení.

Například pro zpracování vztahu mezi objednávkou a zákazníkem může reprezentace objednávky obsahovat odkazy, které identifikují dostupné operace pro zákazníka objednávky. Následující blok kódu je možná reprezentace:

{
  "orderID":3,
  "productID":2,
  "quantity":4,
  "orderValue":16.60,
  "links":[
    {
      "rel":"customer",
      "href":"https://api.contoso.com/customers/3",
      "action":"GET",
      "types":["text/xml","application/json"]
    },
    {
      "rel":"customer",
      "href":"https://api.contoso.com/customers/3",
      "action":"PUT",
      "types":["application/x-www-form-urlencoded"]
    },
    {
      "rel":"customer",
      "href":"https://api.contoso.com/customers/3",
      "action":"DELETE",
      "types":[]
    },
    {
      "rel":"self",
      "href":"https://api.contoso.com/orders/3",
      "action":"GET",
      "types":["text/xml","application/json"]
    },
    {
      "rel":"self",
      "href":"https://api.contoso.com/orders/3",
      "action":"PUT",
      "types":["application/x-www-form-urlencoded"]
    },
    {
      "rel":"self",
      "href":"https://api.contoso.com/orders/3",
      "action":"DELETE",
      "types":[]
    }]
}

V tomto příkladu links má pole sadu odkazů. Každý odkaz představuje operaci související entity. Data pro každé propojení zahrnují vztah (zákazník), identifikátor URI (https://api.contoso.com/customers/3), metodu HTTP a podporované typy MIME. Klientská aplikace potřebuje tyto informace k vyvolání operace.

Pole links také obsahuje informace, které se odkazují samy na sebe, o načtených prostředcích. Tyto odkazy mají vztah sama.

Vrácená sada odkazů se může změnit v závislosti na stavu prostředku. Myšlenka, že hypertext je modul stavu aplikace popisuje tento scénář.

Implementace správy verzí

Webové rozhraní API nezůstává statické. Při změně obchodních požadavků se přidají nové kolekce prostředků. Při přidání nových prostředků se můžou změnit vztahy mezi prostředky a změnou struktury dat v prostředcích. Aktualizace webového rozhraní API pro zpracování nových nebo různých požadavků je jednoduchý proces, ale musíte zvážit účinky, které tyto změny mají na klientské aplikace, které využívají webové rozhraní API. Vývojář, který navrhuje a implementuje webové rozhraní API, má plnou kontrolu nad tímto rozhraním API, ale nemá stejnou kontrolu nad klientskými aplikacemi vytvořenými partnerskými organizacemi. Je důležité pokračovat v podpoře stávajících klientských aplikací a zároveň umožnit novým klientským aplikacím používat nové funkce a prostředky.

Webové rozhraní API, které implementuje správu verzí, může označit funkce a prostředky, které zveřejňuje, a klientská aplikace může odesílat požadavky směrované na konkrétní verzi funkce nebo prostředku. Následující části popisují několik různých přístupů, z nichž každá má své vlastní výhody a kompromisy.

Bez správy verzí

Tento přístup je nejjednodušší a může fungovat pro některá interní rozhraní API. Významné změny mohou být reprezentovány jako nové prostředky nebo nové odkazy. Přidání obsahu do existujících prostředků nemusí představovat zásadní změnu, protože klientské aplikace, které neočekávají tento obsah, ho ignorují.

Například požadavek na identifikátor URI https://api.contoso.com/customers/3 by měl vrátit podrobnosti o jednom zákazníkovi, který obsahuje pole id, name a address, která klientská aplikace očekává.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"id":3,"name":"Fabrikam, Inc.","address":"1 Microsoft Way Redmond WA 98053"}

Poznámka:

Pro zjednodušení příklady odpovědí zobrazených v této části neobsahují odkazy HATEOAS.

Pokud je pole DateCreated přidáno do schématu zákaznického prostředku, pak odpověď vypadá takto:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"id":3,"name":"Fabrikam, Inc.","dateCreated":"2025-03-22T12:11:38.0376089Z","address":"1 Microsoft Way Redmond WA 98053"}

Stávající klientské aplikace můžou dál fungovat správně, pokud můžou ignorovat nerozpoznaná pole. Mezitím lze nové klientské aplikace navrhnout tak, aby zpracovávaly toto nové pole. Může však dojít k výraznějším úpravám schématu prostředků, včetně odebrání polí nebo přejmenování. Nebo se můžou změnit vztahy mezi prostředky. Tyto aktualizace můžou představovat zásadní změny, které brání správnému fungování stávajících klientských aplikací. V těchto scénářích zvažte jeden z následujících přístupů:

Správa verzí identifikátoru URI

Pokaždé, když upravíte webové rozhraní API nebo změníte schéma prostředků, přidáte číslo verze do identifikátoru URI pro každý prostředek. Dříve existující identifikátory URI by měly dál fungovat normálně tím, že vrací prostředky, které odpovídají jejich původnímu schématu.

Například address pole v předchozím příkladu je restrukturalizováno na dílčí pole, která obsahují každou součást adresy, například streetAddress, , citystatea zipCode. Tato verze prostředku může být vystavena prostřednictvím identifikátoru URI, který obsahuje číslo verze, například https://api.contoso.com/v2/customers/3:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"id":3,"name":"Fabrikam, Inc.","dateCreated":"2025-03-22T12:11:38.0376089Z","address":{"streetAddress":"1 Microsoft Way","city":"Redmond","state":"WA","zipCode":98053}}

Tento mechanismus správy verzí je jednoduchý, ale závisí na serveru na směrování požadavku do příslušného koncového bodu. Může se však stát nepraktným, protože webové rozhraní API zraje prostřednictvím několika iterací a server musí podporovat mnoho různých verzí. Z puristova hlediska klientské aplikace ve všech případech načítají stejná data (zákazník 3), takže identifikátor URI by se neměl lišit podle verze. Toto schéma také komplikuje implementaci HATEOAS, protože všechny odkazy musí do identifikátorů URI obsahovat číslo verze.

Verzionování řetězců dotazů

Místo poskytování více identifikátorů URI můžete zadat verzi prostředku pomocí parametru v řetězci dotazu připojeném k požadavku HTTP, například https://api.contoso.com/customers/3?version=2. Parametr verze by měl ve výchozím nastavení použít smysluplnou hodnotu, například 1, pokud ji starší klientské aplikace vynechá.

Tento přístup má sémantickou výhodu, že stejný prostředek se vždy získá ze stejného URI. Tato metoda ale závisí na kódu, který zpracovává požadavek na parsování řetězce dotazu a odeslání příslušné odpovědi HTTP. Tento přístup také komplikuje implementaci HATEOAS stejným způsobem jako mechanismus správy verzí identifikátoru URI.

Poznámka:

Některé starší webové prohlížeče a webové proxy servery neuchovávají odpovědi na požadavky, které obsahují dotazovací řetězec v URI. Neuložené do mezipaměti odpovědi můžou snížit výkon webových aplikací, které používají webové rozhraní API a spouštějí se ve starším webovém prohlížeči.

Správa verzí hlaviček

Místo připojení čísla verze jako parametru řetězce dotazu můžete implementovat vlastní hlavičku, která označuje verzi prostředku. Tento přístup vyžaduje, aby klientská aplikace přidala odpovídající hlavičku do všech požadavků. Kód, který zpracovává požadavek klienta, však může použít výchozí hodnotu, jako je verze 1, pokud je hlavička verze vynechána.

Následující příklady používají vlastní hlavičku s názvem Custom-Header. Hodnota této hlavičky označuje verzi webového rozhraní API.

Verze 1:

GET https://api.contoso.com/customers/3
Custom-Header: api-version=1

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"id":3,"name":"Fabrikam, Inc.","address":"1 Microsoft Way Redmond WA 98053"}

Verze 2:

GET https://api.contoso.com/customers/3
Custom-Header: api-version=2

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"id":3,"name":"Fabrikam, Inc.","dateCreated":"2025-03-22T12:11:38.0376089Z","address":{"streetAddress":"1 Microsoft Way","city":"Redmond","state":"WA","zipCode":98053}}

Podobně jako správa verzí identifikátoru URI a správa verzí řetězců dotazů musíte do všech odkazů zahrnout odpovídající vlastní hlavičku pro implementaci HATEOAS.

Správa verzí typů médií

Když klientská aplikace odešle požadavek HTTP GET na webový server, měl by použít hlavičku Accept k určení formátu obsahu, který dokáže zpracovat. Účelem hlavičky Accept je obvykle umožnit klientské aplikaci určit, zda má být text odpovědi XML, JSON nebo jiný běžný formát, který může klient analyzovat. Je však možné definovat vlastní typy médií, které obsahují informace, které klientské aplikaci umožňují určit, jakou verzi prostředku očekává.

Následující příklad ukazuje požadavek, který určuje hlavičku Accept s hodnotou application/vnd.contoso.v1+json. Prvek vnd.contoso.v1 označuje webovému serveru, že by měl vrátit verzi 1 prostředku. Element json určuje, že formát textu odpovědi by měl být JSON:

GET https://api.contoso.com/customers/3
Accept: application/vnd.contoso.v1+json

Kód, který zpracovává požadavek, zodpovídá za zpracování hlavičky Accept a co nejvíce ho respektuje. Klientská aplikace může v hlavičce Accept zadat více formátů, což webovému serveru umožňuje zvolit nejvhodnější formát textu odpovědi. Webový server potvrdí formát dat v textu odpovědi pomocí hlavičky Content-Type:

HTTP/1.1 200 OK
Content-Type: application/vnd.contoso.v1+json; charset=utf-8

{"id":3,"name":"Fabrikam, Inc.","address":"1 Microsoft Way Redmond WA 98053"}

Pokud hlavička Accept neurčuje žádné známé typy médií, webový server může vygenerovat zprávu odpovědi HTTP 406 (Není přijatelné) nebo vrátit zprávu s výchozím typem média.

Tento mechanismus verzování je jednoduchý a vhodný pro HATEOAS, který umožňuje zahrnout typ MIME souvisejících dat do odkazů na prostředky.

Poznámka:

Když vyberete strategii verzování, bude to mít vliv, a to zejména na ukládání do mezipaměti webového serveru. Schémata správy verzí identifikátorů URI a řetězců dotazů jsou vhodná pro ukládání do mezipaměti, protože stejná kombinace identifikátorů URI nebo řetězce dotazu odkazuje pokaždé na stejná data.

Mechanismy správy verzí hlaviček a typů médií obvykle vyžadují více logiky pro zkoumání hodnot ve vlastní hlavičce nebo v hlavičce Accept. V rozsáhlém prostředí může mnoho klientů, kteří používají různé verze webového rozhraní API, vést k významnému množství duplicitních dat v mezipaměti na straně serveru. Tento problém může být akutní, pokud klientská aplikace komunikuje s webovým serverem prostřednictvím proxy serveru, který implementuje ukládání do mezipaměti a předává požadavek pouze na webový server, pokud aktuálně neobsahuje kopii požadovaných dat v mezipaměti.

Víceklientské webové API

Víceklientské řešení webového rozhraní API sdílí několik tenantů, jako jsou různé organizace, které mají vlastní skupiny uživatelů.

Víceklientská architektura výrazně ovlivňuje návrh webového rozhraní API, protože určuje, jak se k prostředkům přistupuje a jak jsou zjišťovány napříč různými klienty v rámci jedné instance webového rozhraní API. Navrhujte rozhraní API s ohledem na víceklientské prostředí, abyste se vyhnuli potřebě budoucího refaktoringu pro implementaci izolace, škálovatelnosti nebo přizpůsobení specifických pro tenanty.

Dobře navržená rozhraní API by měla jasně definovat, jak se tenanti identifikují v požadavcích, ať už prostřednictvím subdomén, cest, hlaviček nebo tokenů. Tato struktura zajišťuje konzistentní, ale flexibilní prostředí pro všechny uživatele v systému. Další informace najdete v tématu Mapování požadavků na tenanty ve víceklientských řešeních.

Víceklientská architektura ovlivňuje strukturu koncových bodů, zpracování požadavků, ověřování a autorizaci. Tento přístup také ovlivňuje, jak brány rozhraní API, nástroje pro vyrovnávání zatížení a back-endové služby směrují a zpracovávají požadavky. Následující strategie jsou běžné způsoby, jak dosáhnout víceklientské architektury ve webovém rozhraní API.

Použijte izolaci na úrovni subdomény nebo domény (izolace na úrovni DNS)

Tento přístup směruje požadavky pomocí domén specifických pro tenanta. Zástupné domény využívají subdomény ke zvýšení flexibility a zjednodušení. Vlastní domény, které umožňují tenantům používat vlastní domény, poskytují větší kontrolu a dají se přizpůsobit tak, aby vyhovovaly konkrétním potřebám. Obě metody spoléhají na správnou konfiguraci DNS, včetně ACNAME záznamů, a směrují provoz do příslušné infrastruktury. Zástupné domény zjednodušují konfiguraci, ale vlastní domény poskytují více značkového prostředí.

Zachovejte název hostitele mezi reverzním proxy a back-endovým serverem, abyste se vyhnuli problémům, jako je přesměrování adresy URL, a zabránili zveřejnění interních adres URL. Tato metoda zajišťuje správné směrování provozu specifického pro tenanta a pomáhá chránit interní infrastrukturu. Řešení DNS je zásadní pro dosažení umístění dat a zajištění dodržování právních předpisů.

GET https://adventureworks.api.contoso.com/orders/3

Předání hlaviček HTTP specifických pro tenanta

Informace o tenantovi je možné předávat prostřednictvím vlastních hlaviček HTTP, jako jsou X-Tenant-ID nebo X-Organization-ID, nebo prostřednictvím hlaviček založených na hostiteli, jako jsou Host nebo X-Forwarded-Host, anebo je možné je extrahovat z deklarací tokenu JSON Web Token (JWT). Volba závisí na možnostech směrování brány rozhraní API nebo reverzního proxy serveru s řešeními založenými na hlavičce vyžadujících bránu vrstvy 7 (L7) ke kontrole jednotlivých požadavků. Tento požadavek zvyšuje režijní náklady na zpracování, což zvyšuje náklady na výpočetní prostředky při škálování provozu. Izolace založená na hlavičce nicméně poskytuje klíčové výhody. Umožňuje centralizované ověřování, které zjednodušuje správu zabezpečení napříč víceklientovými rozhraními API. Pomocí sad SDK nebo klientů rozhraní API se kontext tenanta dynamicky spravuje za běhu, což snižuje složitost konfigurace na straně klienta. Zachování kontextu tenanta v hlavicích také vede k přehlednějšímu návrhu rozhraní RESTful API tím, že se v identifikátoru URI vyhněte datům specifickým pro tenanty.

Důležitým aspektem směrování založeného na hlavičkách je to, že komplikuje ukládání do mezipaměti, zejména pokud vrstvy mezipaměti spoléhají výhradně na klíče založené na identifikátorech URI a nezohledňovaly hlavičky. Vzhledem k tomu, že většina mechanismů ukládání do mezipaměti je optimalizována pro vyhledávání URI, může spoléhání se na hlavičky vést k fragmentovaným položkám mezipaměti. Fragmentované položky snižují počet přístupů do mezipaměti a zvyšují zatížení back-endu. Kritičtější je, že pokud vrstva ukládání do mezipaměti nerozlišuje odpovědi podle hlaviček, může obsluhovat uložená data v mezipaměti určená pro jednoho nájemce jinému a vytvořit riziko úniku dat.

GET https://api.contoso.com/orders/3
X-Tenant-ID: adventureworks

nebo

GET https://api.contoso.com/orders/3
Host: adventureworks

nebo

GET https://api.contoso.com/orders/3
Authorization: Bearer <JWT-token including a tenant-id: adventureworks claim>

Předání informací specifických pro tenanta prostřednictvím cesty URI

Tento přístup připojí identifikátory tenanta v hierarchii prostředků a spoléhá na bránu rozhraní API nebo reverzní proxy server k určení příslušného tenanta na základě segmentu cesty. Izolace založená na cestě je efektivní, ale ohrožuje návrh RESTful webového rozhraní API a zavádí složitější logiku směrování. Často vyžaduje porovnávání vzorů nebo regulární výrazy k analýze a kanonizaci cesty URI.

Izolace založená na hlavičce naproti tomu předává informace o tenantovi prostřednictvím hlaviček HTTP jako párů klíč-hodnota. Oba přístupy umožňují efektivní sdílení infrastruktury za účelem snížení provozních nákladů a zvýšení výkonu ve velkých webových rozhraních API s více tenanty.

GET https://api.contoso.com/tenants/adventureworks/orders/3

Povolení distribuovaného trasování a kontextu trasování v rozhraních API

Vzhledem k tomu, že se distribuované systémy a architektury mikroslužeb stávají standardem, zvyšuje se složitost moderních architektur. Použití hlaviček, jako například Correlation-ID, X-Request-ID nebo X-Trace-ID, k předávání kontextu trasování v požadavcích rozhraní API je osvědčeným postupem pro dosažení end-to-end viditelnosti. Tento přístup umožňuje bezproblémové sledování požadavků při jejich toku z klienta do back-endových služeb. Usnadňuje rychlou identifikaci selhání, monitorování latence a mapování závislostí rozhraní API napříč službami.

Rozhraní API, která podporují zahrnutí informací o trasování a kontextu, zlepšují úroveň pozorovatelnosti a možnosti ladění. Povolením distribuovaného trasování umožňují tato rozhraní API podrobnější znalosti chování systému a usnadňují sledování, diagnostiku a řešení problémů ve složitých prostředích s více službami.

GET https://api.contoso.com/orders/3
Correlation-ID: 0f8fad5b-d9cb-469f-a165-70867728950e

HTTP/1.1 200 OK
...
Correlation-ID: 0f8fad5b-d9cb-469f-a165-70867728950e

{...}

Model vyspělosti webového rozhraní API

V roce 2008 Leonard Richardson navrhl, co se nyní označuje jako Richardson Maturity Model (RMM) pro webová rozhraní API. RMM definuje čtyři úrovně vyspělosti webových rozhraní API a vychází z principů REST jako architektonického přístupu k návrhu webových služeb. V RMM se s rostoucí úrovní vyspělosti rozhraní API stává více RESTful a přesněji se řídí principy REST.

Jsou to tyto úrovně:

  • Úroveň 0: Definujte jeden identifikátor URI a všechny operace jsou požadavky POST na tento identifikátor URI. Webové služby protokolu Simple Object Access Protocol jsou obvykle na této úrovni.
  • Úroveň 1: Vytvořte samostatné identifikátory URI pro jednotlivé prostředky. Tato úroveň ještě není RESTful, ale začíná odpovídat návrhu RESTful.
  • Úroveň 2: K definování operací s prostředky použijte metody HTTP. V praxi mnoho publikovaných webových rozhraní API odpovídá přibližně této úrovni.
  • Úroveň 3: Použijte hypermedia (HATEOAS). Tato úroveň je skutečně rozhraní RESTful API podle definice Fieldingu.

Iniciativa OpenAPI

Iniciativu OpenAPI vytvořilo oborové konsorcium pro standardizaci popisů rozhraní REST API napříč dodavateli. Standardizační specifikaci se říkalo Swagger před tím, než byla přenesena do iniciativy OpenAPI a přejmenována na specifikaci OpenAPI (OAS).

Možná budete chtít přijmout OpenAPI pro vaše webová rozhraní RESTful API. Vezměte v úvahu následující body:

  • OAS se dodává se sadou názorných pokynů pro návrh rozhraní REST API. Pokyny jsou výhodné pro interoperabilitu, ale vyžadují, abyste měli jistotu, že návrh vyhovuje specifikacím.

  • OpenAPI podporuje přístup založený na kontraktu místo přístupu typu první implementace. Metoda kontrakt nejprve znamená, že nejdříve navrhnete smlouvu rozhraní API a poté napíšete kód, který tuto smlouvu implementuje.

  • Nástroje jako Swagger (OpenAPI) můžou generovat klientské knihovny nebo dokumentaci z kontraktů rozhraní API. Příklad najdete v dokumentaci k webovému rozhraní API ASP.NET Core pomocí Swaggeru nebo OpenAPI.

Další kroky