Best practices for REST API design

E cam simplistic articolul, probleme adevărate cu care m-am lovit personal e când complexitatea creste și treci de CRUD-based interaction.

Sa vezi când baza de date are problemele ei de design ce fun e, sau când.

Recent m-am jucat cu OData și pare sa fie o soluție destul de buna și rapida de pus in the wild.

Sunt curios ce păreri au și alții pt ca nu am găsit pana acum “the silver bullet”.

Nu am lucrat pana acum cu OData
Insa am vazut ca au inceput sa apara si api-uri cu GraphQL. M-am jucat putin cu el vara trecuta. Mi-a placut ca duce cata informatie trebuie, un singur endpoint si poti sa fa faci chiar si chestii mai real time ish prin subscriptions. :slight_smile:

Am lucrat si eu aproape 1 an cu OData, nu mi-a placut :))) Imi da impresia ca te forteaza sa lucrezi cum vrea el, in loc sa poti sa-l folosesti cum vrei tu. Plus ca pare ca ai putea destul de usor sa faci acelasi lucru si fara: foloseste query’uri in url si-ti indica ce entitati si coloane trebuiesc aduse.

In articol sunt best practices basic pe care le gasesti cam peste tot. Deci inca unul la milioanele deja existente, nu difera de celelalte :grinning: plus ca-i putina informatie la volumul ala de text, putea fi mai comprimat cred :))

Intr-adevar, pare un container on top on Entity Framework, eu planuiesc sa il folosesc pentru a expune date pentru consum de catre 3rd party applications gen Power BI.

mi-am adus aminte ce nu-mi placea la OData :))) a anulat ajutorul AutoMapperului pentru transformarea entitatilor in dto-uri si a trebuit sa inlocuim asta cu linq: context.Users.First().Select(entity => new Dto(field1: entity.field1, ....));

aratau oribil controllerele. Or exista practici mai bune si n-am stiut noi de ele atunci … :thinking:

Cel mai urât REST API l-am văzut cu map reduce în memorie cu mongodb fără agregare. Adică te duci din obiect în obiect să colectezi id-uri și să creezi noi obiecte sau să cauți alte obiecte. Adică crud-ul era un chin și nu era totul imutabil.

Dacă ai o structură relationala e foarte enervant de făcut debug că tot trebuie sa te duci din ID în ID.

1 Like

cum ai face tu un rest api?

1 Like

Da, asta mi se pare si mie destul de complex de navigat și de negociat. E un trade-off fin pe care trebuie sa îl faci între complexitatea api-ului, extensibilitatea lui și ease of usage.

OData pare sa rezolve chestia asta pt tine prin dynamic filtering si expand clauses. Chiar sunt curious daca a mai folosit cineva.

Best practices for Rest-ish Api design, poate. Fără hypermedia format, care nu este ușor de ales și un client care să știe să construiască aplicația finală, doar din răspunsul dat de server, este cam greu de realizat un rest api care să fie folosit.

1 Like

E mult mai usor sa generezi un REST API dintr-un API de graphql. Daca eu imi incep un proiect sigur as merge pe graphql din prima, exceptie daca mi-ar trebui performanta cat mai mare, caz in care poate gRPC/websockets cu protobuff/stomp/mqtt ar fi prima varianta.

Daca e nevoie de un Rest API pentru un proiect existent, atunci OpenAPI cu swagger mi se pare cea mai ok solutie, cum in Java/Kotlin poti genera OpenAPI specification-ul din anotari e aproape gratis. La fel Spring are best practices pentru orice îți poți imagina. OpenAPI e o solutie solida fiindca daca ai o specificatie OpenAPI buna ai documentatie automatizata si poti inclusiv genera un API graphql cu el daca chiar vrei. Un mock server cu fake data după response type poate fi iarăși foarte util in CI.

Dacă folosești fastify pe node poți genera api-ul din json-ul de openapi.

La gRPC îți trebuie un proxy precum https://www.envoyproxy.io și ai REST API gratis cu grpc bridge.

1 Like

Pentru realizarea oricărui tip de api este nevoie de anumite cunoștințe tehnice, dar mai întâi m-aș apleca spre designul aplicației în sine, pentru a înțelege unde sunt frontierele din domenii în sens ddd și cum interacționează între ele.
Acuma pentru comunicarea între două servicii, există tot felul de protocoale, sincrone și asincrone, dar pentru comunicarea client-server există doar http în sensul rest(ish),restfull, graphql sau pentru anumite cazuri, există soluții pentru a afișa anumite informații în timp real.
Cred că contează foarte mult și ce fel de model alegem pentru a salva datele, același și pentru scris și citit din baza de date sau eventstore și read models, în complexitatea realizării unui http api. De exemplu, un rest api, pentru mine, ar trebui să fie o poveste spusă în forma unui graf trecând prin diferite stări, cu un format hypermedia corespunzător. Și un client capabil să se folosească de acest api, într-un mod autonom sau fără să consulte prea mult documentația acelui api, și să construiască html final pe care utilizatorul îl vede și cu care interacționează.
Iar pentru a înțelege această poveste, probabil ar trebui trecut prin eventstorming/eventmodeling.
Apropo, de asta, cine este interesat de eventstorming/eventmodeling, se lansează o nouă platformă care te ajută să faci acest lucru și online

1 Like