Sunt curios ce decizii de arhitectura ati lua in urmatoarea situatie: trebuie sa implementati intr-o aplicatie existenta un API REST third-party.
Acest API are peste 40 de endpoint-uri de tip CRUD, dar nu numai, organizate pe categorii, de genul “Products”, “Orders”, “Invoices”, “Sales” etc.
Prin “decizii” ma refer la:
o clasa mamut care cuprinde cate o functie pentru fiecare endpoint?
o clasa care asigura conectarea la API si care are o functie pentru realizarea de call-uri; clasa este extinsa apoi de cate o clasa pentru fiecare categorie?
Sunt foarte usor de administrat endpoint-urile (se bazeaza pe stilul declarativ), si se poate reduce totul la o singura clasa care sa faca call-urile.
Am utilizat aceasta metoda la un proiect si a fost totul super smooth.
La api-ul la care lucrez folosim ceva ce se cheamă cqrs + mediator pattern. Este o biblioteca care implementează acel lucru. Controller-ele doar primesc parametrii care sunt trimiși pe endpint si este apelata o metoda care face handling-ul cu. Folosim un orm pt interacțiunea cu baza de date.
Pt a întoarce răspunsul în json, folosim clase view model unde punem doar ce este de interes.
Nota, acel api este implementat in .net + c#, dar ideea cred ca este buna. Mi se pare ca se obține o buna decuplare si testarea este destul de usoara.
Pe lângă astea, mai sunt si validatoare, clase care reprezinta tabelele din baza de date etc.
Am văzut api-uri cu clase mamut si este foarte greu de lucrat. Te pierzi prin metode.
Am postat acum ceva timp acest articol despre cqrs. Sper sa te ajute.
Poate sunt si alte arhitecturi mai bune, dar cel putin asa este facut acesta la care lucrez
In teorie, luam frumos cartea si citim cum se face la modul “like a sir”. Asta pana intelegi teoria si aflii cum se aplica exact in proiectul tau. In practica vrei sa fii cat mai eficient si nu vrei sa pierzi tare multa vreme pe implementarea unor functii care vor fi prea putin folosite. De aceea eu as face o analiza pentru a afla care dintre endpointuri este de asteptat sa fie cel mai solicitate si apoi as construi arhitectura in principal in jurul acelor endpointuri. Apoi as face mici ajustari pe parcurs, in cazul in care se dovedeste ca un endpoint necesita mai multa/mai putina atentie decat am anticipat. Cred ca ideea asta mai elimina din dilemele pe care le ai legat de decizie.
Ti-am raspuns la intrebarea despre decizia arhitecturala. Linkuri utile cred ca ai primit mai sus suficiente.
Spor!
Putin off-topic, dar e interesant / putin amuzant cum @Cosmin nu a specificat despre ce tehnologie e vorba, @anon48907206 a presupus ca este vorba de PHP si chiar a fost o presupunere corecta PHP = default language
PHP = default language