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

1 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
16 harrison314
odpověděl/-a 12.6. 12:03
 
upravil/-a 14.6. 7:31

Pozor WebApi sluzi na vytvorenie REST sluzby, zatial co WCF na vytvorenie webovej sluzby. Ide o dve filozificky odlisne veci.
REST je na volanie CRUD operacii (POST, GET, PUT, DELETE) a webove sluzby sluzi na vzdialene volanie operacii.

Edit:
Este dost podstatny rozdiel medzi REST-om a webovymi sluzbami, REST je naviazany na HTTP, zatiacl co webove sluzby su agnosticke veco formatu kodovania a prenosovemu kanalu, tak sa daju velmi vyhodne pouzit v message queue, alebo pre extremistov cez smtp.

Pouzivat WebApi, na komunikaciu s javascriptom na strane klienta je podla mna uplne v pohode. No pouzivat ich na komunikaciu medzi servermi uz nie, tam by som jednoznacne volil webove sluzby.

Problemi, ktore spominas su podla mna z toho, ze sa snazite pouzit REST ako webove sluzby (znasilnovanie technologie).

Aj k web api vies automaticky generovat klienta (cez swagger), alebo vo firme som robil interny tool generujuceho Typescript klienta.
V .Net Corie vies spravit WCF clienta a v 1.1 vies spravit aj WCF server s basichttp bindingom aj server cez nejake tretostranne kniznice (ak bude zaujem pohladam link).

Komentáře

  • archenroot : "REST je na volanie CRUD operacii" - to samozrejme neni pravda. REST i SOAP jsou sluzby, kazda operujena urovni jinych predikatu, ale nevidim duvod, proc nepouzivat REST architekturu pro business operace. Naopak. 3.12. 16:47
  • harrison314 : Poprosim priklad. 3.12. 18:20

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.