Jak verzujete REST API? rubrika: Programování: Jiné

9 Honza Břešťan
položil/-a 5.6.2013

Narazil jsem na problem verzovani API a rad bych zjistil, jak verzujete vy a jestli k memu reseni mate nejake pripominky, klidne i literaturu, jak bych ho mohl vylepsit.

Predem podotykam, ze asi jedine mozne reseni je verzovat URI - data versioning pro me neni vhodny (je absolutni horor udrzovat si prehled, kde jaky field muze chybet nebo prebyvat a mit podle toho dokumentaci a kontrakty pro (de)serializer).

Nase REST sluzby jsou psane pomoci WCF; jsou to selfhosted WCF sluzby s endpointy zverejnene pres WebGetAttribute a WebInvokeAttribute. Pisu to proto, ze jsem neprisel na zpusob, jak mit vic URI zpracovanych jednou metodou. S WCF toho moc neudelam, ma svoje vyhody a nevyhody a je nad tim uz hotova infrastruktura. Otazka je ale nezavisla na jazyku a frameworku.

Dosavadni URI jsou hodne divoke, nekonzistentni, vetsinou to jsou slovesa/akce a ne resources. Postupne bych ale rad nasadil nasledujici format:

/Service/Resource/Version/?param={...} pro GET
/Service/Resource/Version/ plus postdata pro ostatni akce

Kamen urazu je v te verzi - v te WCF implementaci jsou jednotlive akce (GET, PUT...) routovany uplne nezavisle, takze by slo je i zvlast verzovat. Na jednu stranu mi to nedava smysl, protoze mi prijde lepsi verzovat cely resource, na druhou stranu ale WCF neumi (nebo jsem to neobjevil) k existujici metode pridat novou routu s vyssi verzi. Musel bych vytvorit novou metodu, ktera jen vola stejnou logiku. Nakonec jsem se rozhodl verzovat cely resource, ale jak to dava smysl vam?

Tim padem neumim jednoduse dosahnout stavu, kdy treba bude stejna logika a format GETu pro
/Service/Resource/ (vzdy by mela brat latest verzi API)
/Service/Resource/V2.1/ (explicitni latest verze)
/Service/Resource/V2/ (stejna logika a format jako pro V2.1, menila se nejaka jina akce)
Musel bych udrzovat hodne kodu, nezapominat presmerovavat tu implicitni verzi atd.
Muze tohle byt velky problem z pohledu (obecnych) API consumeru? Nebo idealne vite nekdo, jak tohle resit s WCF?

A jedna obecnejsi na zaver, jak verzujete na svych projektech a jake s tim mate zkusenosti?

odkaz Vyřešeno
8 Jakub Macek
odpověděl/-a 6.6.2013

Doporučoval bych zvážit, jestli se krokují verze jednotlivých zdrojů (resp. funkcí, které s nimi pracují), nebo je to celá služba, nebo dokonce celé API. První variantu bych považoval za chaos-generující, protože časem musí některé verze přejít do stavu nadbytečné a odstraněné - v takovém případě by bylo dost složité se v tom vyznat (bude funkční v3 a v4 pro GET a v2 pro POST). Pokud to cyklus vydání dovolí, doporučuji poslední variantu.

Potom je nejpřehlednějsí URL prefix (api.example.com/v1/service1/resource1/) nebo doménový prefix (v1.api.example.com/service1/resource1/). Samotné služby by pak byly adaptéry kolem logiky uvnitř, která už se může verzovat na úrovni funkcí.

Komentáře

  • Honza Břešťan : Diky, mam podobny nazor, jen prave verzovani celych sluzeb (celeho API asi ne) znamena v tom WCF hlidat si routovani rucne, coz je trochu overhead. To ale zase mozna pujde vyresit z rad od Petra Vonese. 6.6.2013
  • Jakub Macek : Ještě doporučuju nahlédnout na ASP.NET Web API. Zatím jsem to nepoužil, ale je to zacíleno na REST. Osobně se mi to routování konvencí uvnitř zdá trochu víc magické než je vhodné, ale zdrojáky jsou k dispozici a z mojí zkušenosti napsat vlastní třídu na routování konvencí není obtížné. 7.6.2013

Pro zobrazení všech 6 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.