it-swarm-eu.dev

Jak fungují webové API?

Slyšel jsem o mnoha webových rozhraních API, jako je Facebook, Twitter atd., Které pomáhají třetím stranám získat přístup k datům a manipulovat s nimi. Chtěl bych vědět, jak funguje webové API. Jaké jsou základy webového rozhraní API?

Pokud chci pro své stránky vytvořit rozhraní API, aby k němu mohli lidé přistupovat nebo jej aktualizovat, s čím musím začít?

17
Harish Kurup

Nejjednodušší je vytvoření sady požadavků GET/POST, které může kdokoli zavolat a zveřejnit informace o adresách URL, parametrech a účincích. GET požadavky pouze pro čtení úkoly a POST požadavky na cokoli, co změní data na serveru.

V případě potřeby přidejte do ověřovacího systému a máte sami jednoduché webové rozhraní API.

A Web API je pouze Rozhraní umožňující přístup k vašemu systému (jako je web) přes standardní metody požadavku HTTP . Samotná data jsou obvykle zabalena v některém standardním formátu (například JSON nebo XML ) pro usnadnění manipulace.


Zde je příklad Web API pro 'TextWise'

23
Dan McGrath

Nyní ve skutečnosti vyvíjím API pro virtualizační platformu mé společnosti. Můžete o nich jít několika různými způsoby, ale moje oblíbená (a nejrychlejší cesta k tomu, aby něco fungovalo, aby lidé mohli rozumět), je použití jednoduchých požadavků HTTP GET a vrácení odpovědi JSON.

Moje adresa URL vypadá takto:

domain.com/method/call/subcall?key=key&data=something

Poté rozebírám proměnné HTTP GET a dělám, co s nimi chce volající udělat. Jedním z největších důvodů, proč jsem se přihlásil jako beta uživatel k vývoji rozhraní Stack Exchange API, bylo to, že jsem věděl, že to bude obrovská zkušenost s učením, a ve skutečnosti to bylo .

Obvykle vracím dvě pole kódovaná JSON, z nichž jedno je result, což v podstatě jen říká, zda byl hovor úspěšný, a pokud není, uvede kód chyby/chybový řetězec. Druhý se obvykle nazývá data a jeho obsah je popsán v dokumentaci konkrétního hovoru. Navíc je API API založené na GET mnohem snazší testovat a ladit.

Existuje spousta dalších formátů, například SOAP/XMLRPC, jen zjišťuji, že volba JSON mi dává neuvěřitelnou jednoduchost a svobodu volby).

Například, pokud potřebuji poslat hodně polí polí a nechci se vypořádat s tunou proměnných GET, mohu to udělat ( příklad v PHP)

$to_send = base64_encode(json_encode($some_array));

To je na druhé straně snadno dekódováno, díky čemuž mohu pracovat s desítkami proměnných, zatímco prostřednictvím API přijímám pouze 2 - 3 proměnné GET.

Jen se snažím udržet své metody a hovory krátké a stručné a navrhnout je tak, aby každé volání vrátilo jednotnou „opracovanou nebo neúspěšnou“ odpověď, po které následovaly požadované údaje.

5
Tim Post

To je vlastně velmi široká otázka. V nejzákladnějším smyslu funguje webové rozhraní API, když klient (jako webový prohlížeč) vytvoří nějaký požadavek HTTP na webový server. Server prozkoumá tuto žádost, aby zjistil, co uživatel chce, a poté vrátí data v nějakém formátu (jako je stránka), který poté klient prozkoumá, aby získal, co chce. Jedná se pouze o jediné věci, které mají společná webová API; Uvědomuji si, že to opravdu neodpovídá na vaši otázku, ale chtěl jsem uvést důvod, proč je otázka tak široká.

Existují nejrůznější způsoby, jak by klient mohl svůj požadavek naformátovat nebo aby server mohl naformátovat jeho odpověď, a tak aby některý z nich měl smysl, musí se klient a server dohodnout na některých základních pravidlech. Obecně řečeno, v dnešní době existují dva velmi obecné styly, které si na tento druh věcí zvyknou.

Vzdálené volání procedur (RPC)

Ve API stylu RPC obvykle existuje pouze jedna URL pro celé API. Tomu říkáte POSTing nějakého dokumentu, který obsahuje informace o tom, co chcete dělat, a server vrátí dokument, který má to, co chcete. Obecně lze říci, že dokument žádosti má obvykle název funkce a některé argumenty.

Některé standardy pro tento styl API zahrnují XML-RPC a SOAP. Tyto standardy se pokoušejí vytvořit formát, který lze použít k popisu volání funkcí, které provádíte, nebo dokonce k popisu celého API.

Reprezentativní státní převod (REST)

V rozhraní API REST) nemáte tolik adresu URL pro rozhraní API jako jmenný prostor : server nebo složka uvnitř serveru, kde je umístěno mnoho různých objektů, a každá adresa URL v tomto jmenném prostoru se stává součástí rozhraní API. Místo toho, aby řekla serveru, že chcete API používat, řekne URL serveru, co chcete použít API na . Poté pomocí metody HTTP a případně těla požadavku vysvětlete, co chcete dělat na , že objekt: GET (načíst něco, co už existuje), POST (vytvořit něco nového), PUT (nahradit něco, co již existuje) ) nebo DELETE (zbavte se něčeho, co již existuje). Existuje několik dalších sloves, která můžete použít, ale ty jsou zdaleka nejběžnější.

Zatím jsem nezmínil standardní formáty pro REST. Teoreticky byste mohli použít téměř jakýkoli formát. HTTP již umožňuje říkat, co chcete dělat a co chcete dělat, takže formát těla požadavku může být téměř cokoli: nějaké znázornění objektu, který chcete vytvořit nebo nahradit. V praxi však autoři REST) autoři inklinují shodnout se na formátu stejně, protože by bylo obtížné pochopit každý možný formát.

2
The Spooniest