WebAPI - business logic

[SideShow]

Hallo

Hoe zouden jullie een webAPI opzetten? Is dit volgens jullie puur en alleen een soort resource pool, een veredelde databank bijna, waar je hoogstens zaken als filters, sortering en paging implenteert in een lijst action, naast de default actions zoals post en delete? Waarbij je dan aparte DLL's maakt die, business logica gewijs, gebruik maken van de resources, om deze eventueel op hun beurt door te sluizen naar de front end applicatie?

Of zien jullie het anders? De webAPI staat veel dichter bij een toepassing en omarmt zélf alle business logica?

[Avalaxy]

Je web API is gewoon een van de potentieel meerdere manieren om je service te gebruiken. Een andere manier zou bijvoorbeeld een MVC-project zijn.

Je web API hoort dus meestal los te staan van je business logic, omdat je die business logic door verschillende projecten wilt kunnen gebruiken. Dat betekent dan ook meteen dat je je business logic in een eigen project stopt. Los daarvan wil je niet in elke controller je business logic herhalen, dus het is sowieso een goed idee om die ergens anders weg te zetten.

Paging hoort overigens meestal niet alleen in je API maar in de hele chain van API tot DAL, omdat je waarschijnlijk server-side wilt pagen en niet de complete collectie op te hoeven halen.

[Mercatres]

Je WebAPI is inderdaad niets meer dan een front voor je business logic, een manier om die business logic aan te spreken. Het voordeel van een WebAPI t.o.v. bvb. WCF is dat je je business logic heel duidelijk exposed en dus ook heel makkelijk mee kunt communiceren. Het is ook een stuk simpeler om met andere talen te communiceren met die API.

@Avalaxy, het is zelfs zo dat Web API in feite een MVC-project is, alleen zijn je controllers API-controllers in plaats van de default controllers van MVC

[Laurens-R]

@Mercatres: Dat geld natuurlijk alleen als we het over ASP.Net web api hebben. Ik geloof dat de vraag eerder ging over web API's in het algemeen; los van implementatie.

Het fraaie van web API's vind ik dat het idd een interface aanbied voor business logic, maar het meest fraaie vind ik nog dat je de business logic en het gebruik daarvan compleet kan loskoppelen. Maw. Men kan de business logic totaal herschrijven zonder dat de interface ook maar 1 procent wijzigt.

Voorbeeld: Men beslist dat klantinformatie ipv in een custom database in een CRM pakket weggeschreven moet worden via een gespecialiseerde service bus. Je API interface wijzigt in principe niet (aangenomen dat de data definitie hetzelfde blijft), terwijl de business en data layer behoorlijk gewijzigd worden.

Als je echt je best doet, implementeer je dan ook nog versioning in je API, zodat je meerdere versies van je API interfaces kan aanspreken (v1, v2, v3). Dat is bijvoorbeeld handig voor het ondersteunen van legacy apps/front ends.

[ Voor 19% gewijzigd door Laurens-R op 26-01-2015 11:31 ]

[SideShow]

Ok bedankt voor de input. Ik laat alvast mn idee over een webAPI als veredelde databank, varen. Volgens jullie hoort de business logic achter die api te zitten.

[Megamind]

SideShow schreef op maandag 26 januari 2015 @ 20:56:
Ok bedankt voor de input. Ik laat alvast mn idee over een webAPI als veredelde databank, varen. Volgens jullie hoort de business logic achter die api te zitten.

Kijk eens naar OData, dat is denk ik wat jij bedoeld.

[Avalaxy]

OData is erg gevaarlijk. Je wilt niet dat mensen zomaar je API aan kunnen roepen met allemaal filters en andere zooi die je database traag maken.

[Kajel]

OData is niet alleen erg gevaarlijk, het is ook ontzettend misleidend. Het wekt de schijn van een REST API, zonder zich aan de geschreven en ongeschreven best practices rondom REST APIs te houden.
Ik vind OData persoonlijk een ontzettend lelijk gedrocht van een "standaard" waar je verre van moet blijven.

Nu even antwoord op de vraag van de TS: Of je veel of weinig business logic achter je API stopt, is geen wetmatigheid. Dat hangt van de situatie af. Soms wil je dat je API enkel een interface is die min of meer enkel CRUD operaties op je database "exposed", maar soms wil je dat er binnen je API veel meer gebeurt met de data, voordat die data gepresenteerd wordt. Overigens hangt het ook een beetje af van het type API dat je bouwt. Je hebt het over een "web API", en anders dan dat je daarmee doelt op een interface die benaderbaar is over het web, weet ik verder niet wat je daarmee bedoelt (een of ander .NET eigen constructie?). Als je een REST API bouwt, dan draait het doorgaans om het blootstellen van data aan de buitenwereld. De beste REST APIs (degene die het meest te rijmen zijn met de standaarden/best practices) bieden voornamelijk een CRUD interface op de data, met in meer of mindere mate wat extra business logica ertussen. Als je daarentegen een SOAP API bouwt, dan denk je meestal in termen van operaties i.p.v. data.

Maar goed, als we enkel kijken naar REST API's, ook dan kun je meer of minder business logica hebben. Laten we Twitter en Facebook als voorbeeld nemen:

Beide sociale netwerken kennen het concept van status messages, waarbij je "timeline" een combinatie is van status messages van al je vrienden. Bij Twitter worden deze in zijn totaliteit, in omgekeerd chronologische volgorde via de API aangeboden. Er is dus weinig sprake van business logica, het gaat enkel om het opvragen van alle berichten van vrienden van de geauthenticeerde gebruiker.
Bij Facebook daarentegen, bestaat je "timeline" uit de berichten van je vrienden die uitgekozen zijn door FB's algoritmes. M.a.w., je krijgt niet alle berichten te zien. Dit is volgens mij bij hun API ook het geval. Er komt dus best wat business logica aan te pas, voordat de data door de API uitgespuugd wordt.

Zoals je ziet, heb je zelf de keuze hoeveel business logica er achter je API zit, zowel in de keuze van het "protocol" (REST vs SOAP), maar ook daarna nog in de implementatie. Al is het wel zo, dat er bijna per definitie makkelijker is om een business-logica-arme REST API te hebben dan hetzelfde bij een SOAP API.

[Caelorum]

Kajel schreef op zondag 01 februari 2015 @ 16:28:
[...]Je hebt het over een "web API", en anders dan dat je daarmee doelt op een interface die benaderbaar is over het web, weet ik verder niet wat je daarmee bedoelt (een of ander .NET eigen constructie?). [...]

Asp.net WebAPI is een framework van Microsoft om REST api's te bouwen. Zoals ze het zelf omschrijven:

ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.

[Kajel]

Verwarrend, aangezien TS zijn post zo begint:

Hoe zouden jullie een webAPI opzetten?

[Avalaxy]

Conceptueel maakt het geen donder uit of je de .NET-implementatie of iets anders gebruikt

[Kajel]

Niet helemaal waar. In theorie zou het idd zo moeten zijn dat implementatie/library/whatnot niks uit zou moeten maken, maar als je .NET gebruikt, en je daarmee de kant van OData opgeduwd wordt, dan maakt het wel degelijk uit.

Ik zou overigens liever zien dat mensen inhoudelijk reageren op mijn post, dan met zulke trivialiteiten

[ Voor 20% gewijzigd door Kajel op 01-02-2015 19:23 ]