Proč vlastně WebAPI? rubrika: Programování: .Net

2 david.muzatko
položil/-a 12.6. 8:57

Ahoj, ani tak né otázka, spíše trochu povzdech, ale zajímaly by mě názory ostatních.

Pohybuji se teď v týmu, kde se používá WebAPI, protože je prostě cool, moderní, úžasné a dokonalé. Mně to připadá jako úchylný krok zpět. Ještě bych pochopil, proč to MS udělal, ale proč se do toho všichni ženou už ne.

Před nějakou dobou jem dělal na větším projektu, kde jsme službu pro ajax řešili jednoduše pomocí WCF, které bylo snadno nakonfigurováno na Json. Bylo to:

  • typové
  • tím pádem to šlo snadno testovat (když metoda vrací int a nespadne tak opravdu vrátila int, žádné dodatečné dotazy na IActionResult apod.)
  • všechno šlo metodou post
  • WCF si poradila i se složitými parametry, nebyly nutné žádné bindery, neřešila se také pádem velikost parametrů (u get se složitým filtrem ty url vypadají vpravdě děsivě a garanci, že se na server dostane všechno stejně nemám)
  • v js byla jednoduchá funkce callScv(methodName, data, success, error), která zastřešila dotazy pomocí jquery.ajax, nastaveno na pevno na post a json v datech. Použití bylo jednotné, prostě stačilo napsat funkci do wcf a uniformě ji v js zavolat.

Jak koukám na webapi, tak všechno jednoduchý na wcf je ve webapi prostě špatně. V js se řeší sestavování url (fuj), podle kontextu se musí ještě volit správná http metoda a podle ní různé balení parametrů buď do dat nebo do url (dvakrát fuj). Testování je zbytečně složité. Nemusí tu být žádný contract, pomůcky jsou, ale stejně neřeknou třeba resulttype. Veškeré FromBody, FromUrl a nedejbože ještě přímý přístup na RouteData jsou podle mě jen generátory těžko nalezitelných chyb.

Čili by mě zajímalo, kde je tedy ta přidaná hodnota, proč je to teď tak moderní. Argument, že .Net.Core (ještě pořád) neumí WCF server nepovažuji za přidanou hodnotu, to je jen moc smutné.

odkaz
18 Petr Voneš
odpověděl/-a 12.6. 11:14
 
upravil/-a 12.6. 11:28

Naprosto chápu. Tady se znovu vymýšlí kolo. Webové služby které poskytují jasně typový popis rozhraní pomocí WSDL, které stačí (v každém normálním nástroji) naimportovat, takže během okamžiku mám kompletní typový klientský kód pro volání, jsou stále nepřekonané. Dnes je v tomto svět zase o 20 let zpět v době "stringové" a týden se řeší v jakém formátu je datum ... strašný. Naprostá neproduktivita a ztráta času nečím, co už bylo dávno vymyšlené.

To je střet vyspělé kultury (XML, SOAP) s dobou kamennou (JSON nebo skládání stringů do URL). JSON neměl nikdy opustit interní formát pro komunikaci ve webových aplikacích. Dnes z něho ovšem dělají veřejná "API" a postupně i druhé XML. Nejdřív zjistili že jim chybí schema, pak že jim samozřejmě chybí jmenné prostory. Pak že dotazovcí jazyk atd.

Komentáře

  • Kit : JSON se na nic jiného, než na komunikaci s Javascriptem, nehodí. XML zatracují jen ti, kteří mu nerozumí. Na druhou stranu je obvyklé, že v dotazech se používá metoda GET, ve které se nic jiného, než skládání URL, dělat nedá. 12.6. 12:00
  • Žížala : Problém je v tom, že spousta vývojářů dodnes nezvládla XML, natož SOAP. Např. od jednoho německého velkoobchodníka dostáváme neustále faktury v buglém XML. 3 roky trvalo, než to naprogramovali. A i teď stále posílají nevalidní XML. Je to obalené HTML hlavičkou, CDATA jim nic neříká a klidně v obsahu elementu pošlou HTML tag. Takže jsem sice napsal script pro import jejich faktur, ale nejdřív mě to zodpovědná slečna pošle, já z toho udělám validní XML a ona si to pak naimportuje do našeho ERP přes moje udělátko... A to je prosím firma, jejíž obrat se pohybuje ve stovkách miliónů euro ročně... Ať žije německé IT. A o holanďanech radši nemluvím, pro ty je to úplně sprosté slovo. A francouzi úplně to samé. CSV je nejvíc co zvládají... Ale pořád lepší než některé české firmy, které pošlou screenshot z excelu s aktuálním ceníkem pro nás a zbytek v JPG začerní, abychom neviděli ceny pro konkurenci... 12.6. 12:01
  • Petr Voneš : @Žížala Protože to generují ručně jako string, takových paskvilů už jsem viděl. Import byl často parsován po řadcích textu regexem, takže samozřejmě záleželo na formátování a někde i mezerách. Hlavně že mají plnou stěnu ISO certifikátů ... 12.6. 12:12
  • harrison314 : :D ISO certifikaty v praxy znamenaju, ze firemne dokumenty maju rovnaku hlavicku a predpisi maju spisane v nejakom dokumente, od toho netreba ocakavat viac 12.6. 12:26
  • pilif : Hmm, zrovna teď pracujeme na relativně rozsáhlé aplikaci (ERP) kde bychom měli implementovat WebAPI. Nad WCF jsem také uvažoval, ale klienti mohou být různé implementace: Android nativní aplikace, SW třetí strany, PHP webserver,... Primárně ovšem poběží lokálně v intranetu. Je tedy v tomto případě WebAPI nevhodná volba? 12.6. 21:19
  • vojta.tranta : Ten JSON tam je hlavně proto, že je lidsky čitelný a malý, asi proto se používá pro webové apky. Ono dneska se razí filozofie GraphQL nebo Falcoru, která je v podstatě to samé schéma, které dělá SOAP, ale má tá pár vychytávek, že jsi člověk může nakonfigurovat přesně jakou chce odpověď vše mu přijde ve tvaru, jaký chce. 13.6. 12:46
  • harrison314 : Nie je GraphQL iba na dopytovanie? IMHO, davno predtym existovali OData. 13.6. 13:20
  • Kit : @vojta.tranta: XML je také lidsky čitelné a malé. Při správném návrhu může být ještě menší než odpovídající JSON. JSON se hodí pro komunikaci s Javascriptem, protože vyhovuje jeho potřebám. 13.6. 14:49
  • Petr Voneš : Jenže OData jsou od Microsoftu, takže málo blbé pro "stringování" :-) 13.6. 16:47
  • harrison314 : @pilif: Na takom mieste by som volil webove sluzby, a pre technologie, ktore desat rokov nie su schopne implementovat standardy, tak by som spravil REST fasadu. A implementoval len to co potrebuju so zjednouchsenm rozhranim. 13.6. 18:26
  • vojta.tranta : @harrison314 graphQL umí i mutace, kde si navolíš, jakou chceš odpověď. 16.6. 1:07
  • harrison314 : @vojta.tranta: skor som myslel na update, create, delete. Trochu offtopic, ale preco znetvorili JSON? A ako je to z bezpecnostou GraphQL. 16.6. 7:47
  • langpavel : @harrison314 GraphQL má možnosti, které stávající technologie neměly. S bezpečností je to všude stejné. Může být dokonalý model který nějaké pako ignoruje a pak stojí za houby. Lze používat všechny metody zabezpečení které jsou jen na úrovni HTTP myslitelné a i víc, GraphQL není omezeno jen na jeden transport, je to spíš jazyk. GraphQL lze zabezpečit na úrovni jednotlivých fieldů ale i na úrovni datových typů a je možné veřejně vystavit jen podmnožinu typů (v reflexi schématu) nebo celé schéma schovat - což mi ale připomíná více security by obscurity. GraphQL je jazyk který si můžete v rámci vašich potřeb omezit 16.6. 23:55

Pro zobrazení všech 5 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.