Průzkum: Jak řešíte API ve svých aplikacích?

2bfree

Rád bych udělal takový průzkum, jakým způsobem řešíte vytvoření API pro vaše aplikace?

Jde mi o to, zda-li používáte nějakou již hotovou knihovnu (vlastní/free/placená) a případně jakou nebo jestli to v každé aplikaci řešíte zvlášť?

Kolik vám řádově (hodiny, dny, … ) zabere přidání podpory API do stávající aplikace a kolik zabere přidání nové metody API?

Podporujete v API více formátů najedou (XMLRPC, JSONRPC, XML REST, JSON REST, SOAP, …)?

Postupuje vaše API něco jako JSON Schema Service Descriptor nebo obdobu pro jiný druh API?

Když se změní definice volané metody, musíte něco upravit i kvůli API?

A jsou vaše MVC aplikace připraveny (z pohledu bezpečnosti¨) na to, že by se zavolali metody modelu přímo, nebo máte nějakou aplikační logiku jinde?

Předem díky za každý postřeh / zkušenost

Robin Martinez

Já si teda vždycky (párkrát v životě) api dělal sám. Vždycky pouze v JSON REST, nic jinýho nebylo potřeba. Je pravda, že to byly jednoduchý věci, ale rozšířit to asi nebylo složitý…

2bfree

Díky za zkušenost,

zajímalo by mne v takovém případě, zda-li by si ocenil existenci knihovny, kterou bys nahrál přes composer, a v konfiguraci bys jí předal seznam service, pro které bys chtěl API a o zbytek by se postarala? Samozřejmě s možností detailnější konfigurace. A když by si stál před otázkou vývoje dalšího API, napadlo by tě takovou věc hledat?

3ugeene napsal(a):

Já si teda vždycky (párkrát v životě) api dělal sám. Vždycky pouze v JSON REST, nic jinýho nebylo potřeba. Je pravda, že to byly jednoduchý věci, ale rozšířit to asi nebylo složitý…

Robin Martinez

Já myslim, že je lepší si to api psát sám od začátku (pokud je čas, prostředky) – máš nad tím absolutní kontrolu a dělá to to, co chceš, nic víc, nic míň.

Ale ještě jednou opakuji – moje api měly vždycky pár funkcí a jednalo se o menší projekty. Třeba tu někdo bude mít zcela opačný názor.

stekycz

Za mě jsou při implementaci API důležité následující vlastnosti

podpora správy přístupu (oAuth nebo jiná access_token based metoda)
routování na presentery na základě HTTP metod
co nejjednodušší přístup ke složení response, ať už mám data jako pole, entity nebo něco jiného
automatický error presenter, který nikdy (pokud nebude chyba v samotném error presenteru, pak to skočí na výchozí nette presenter) nepošle nic jiného než komunikační formát dat (JSON)
detekce některých parametrů na základě HTTP hlaviček (např. požadovaný formát pro response, když jich chci podporovat více)
podpora pro logování raw dat z pro celý request/response
přístup k poslaným datům nikoli jako k JSONu nebo jinému formátu, ale přes parametry action/render, post nebo přes formulář

Zatím jsem nepracoval s ničím, co by tohle vše podporovalo. Vím, že existuje Restful, ale zatím jsem vždy pracoval s vlastním řešením (především kvůli legacy kódu).

Casper

Zdravím, používám právě zmíněný Restful, který splňuje většinu věcí co píše stekycz. Sám jsem si musel dopsat akorát ten „error presenter“** a logování kompletních request-response. Co je asi největší mouchou téhle knihovny je nefunkčnost vytváření odkazů a zčásti i problém mezi rozpoznáním JSON a XML pole.

Spolu s tím používám OAuth 2.0 knihovnu, kde je zase trochu trabl s používáním tamních Request a Response objektů, nicméně je to řešitelné a víceméně i testovatelné. Samozřejmě jsem si musel implementovat své Storage.

** To zpracování errorů by v jiné aplikaci ani možná nebylo třeba hackovat tak jako jsem to dělal já, ale musel jsem zachovat velice obecnou routu, která normálně sežere všechno a přesto jsem chtěl, aby cokoli začínající na /api vrátilo API response (JSON / XML / urlencoded).

2bfree

stekycz napsal(a):

Za mě jsou při implementaci API důležité následující vlastnosti

podpora správy přístupu (oAuth nebo jiná access_token based metoda)

routování na presentery na základě HTTP metod

co nejjednodušší přístup ke složení response, ať už mám data jako pole, entity nebo něco jiného

automatický error presenter, který nikdy (pokud nebude chyba v samotném error presenteru, pak to skočí na výchozí nette presenter) nepošle nic jiného než komunikační formát dat (JSON)

detekce některých parametrů na základě HTTP hlaviček (např. požadovaný formát pro response, když jich chci podporovat více)

podpora pro logování raw dat z pro celý request/response

přístup k poslaným datům nikoli jako k JSONu nebo jinému formátu, ale přes parametry action/render, post nebo přes formulář

Zatím jsem nepracoval s ničím, co by tohle vše podporovalo. Vím, že existuje Restful, ale zatím jsem vždy pracoval s vlastním řešením (především kvůli legacy kódu).

Díky za postřehy,

k tomu oAuth: Zvažuju variantu, že by se mělo ověřovat oprávnění nad voláním dané funkce modelu oproti Nette Identite na úrovni presenteru. A získání Identity by bylo implementovane jako oAuth. Co si o tom myslíš?
přístup k poslaným datům přes parametry action/render …: Tomuhle úplně nerozumím jak myslíš.

IMHO dává smysl mít možnost konfigurace rout, abych si mohl nastavit, na které adrese naslouchá API. Pak by měl IMHO přijít automat, který na základě parametrů detekuje jestli se jedná o XML/JSON RPC/SOAP/REST, na základě toho vytřískat z requestu vše potřebné. Vytřískaná data natypovat (cast|hydrate) podle potřeby a zavolat příslušnou metodu a pak totéž zpět.

Chápu, že by se ti mohlo hodit mít možnost nastavit, že při volání nějaké metody bys chtěl vstupní parametry nějak upravit, nebo upravit výstup. K tomu ale není potřeba hned upravovat presenter. To by snad mělo stačit nastavit vlastní implementaci casteru|hydratoru.

Co bys ještě chtěl třeba ještě řešit v presenteru?