Administratorii pot publica endpoint-uri REST din portalul intern, fără să scrie cod. Fiecare endpoint rulează o regulă App Maker, iar sistemele externe îl apelează ca clienți API autentificați prin OAuth 2.0 client credentials.
Unde se administrează endpoint-urile
Endpoint-urile se administrează în portalul intern, în Management conținut › Endpoints. Ecranul are trei taburi: Endpoints, Clienți API și MCP. Doar utilizatorii cu rolul Security administrator le pot administra; bridge-ul de API verifică rolul pe sesiunea de portal a utilizatorului autentificat.
Bridge-ul de API este componenta care servește endpoint-urile publicate. Își păstrează configurația și jurnalele de apeluri în propria bază de date PostgreSQL și gestionează singur securitatea, limitarea ratei de apeluri și jurnalizarea.
Definirea unui endpoint
Fiecare endpoint apare ca un card cu metoda, denumirea, ruta și regula pe care o rulează.
| Setare | Rol |
|---|---|
| Metodă HTTP | GET, POST, PUT, PATCH sau DELETE |
| Denumire | Identifică endpoint-ul în portal |
| Rută | Calea, sub prefixul API-ului public, la care este publicat endpoint-ul |
| Modul și regulă | Modulul și regula App Maker care rulează la apelarea endpoint-ului |
| Parametri | Parametri tipizați, care pot fi imbricați; cererile sunt validate pe baza lor |
| Scope obligatoriu | Scope-ul pe care trebuie să îl conțină token-ul clientului pentru a apela endpoint-ul |
| Activ | Un comutator care publică sau retrage endpoint-ul |
| Consolă live | Afișează apelurile endpoint-ului pe măsură ce au loc |
Logica de business rămâne în regulile App Maker. Un endpoint stabilește doar cine poate apela o regulă, cu ce parametri și pe ce rută.
Cum este procesat un apel
- Sistemul extern cere un token de la
/oauth/token, cu grant-ul client credentials. - Bridge-ul returnează un JWT cu valabilitate scurtă, care conține scope-urile clientului.
- Sistemul apelează ruta endpoint-ului cu token-ul în antetul
Authorization: Bearer. - Bridge-ul validează token-ul, scope-ul obligatoriu și parametrii.
- Bridge-ul rulează modulul și regula în App Maker Engine și returnează rezultatul.
Exemplu de apel către un endpoint POST publicat, după obținerea token-ului:
curl -X POST https://<your-portal>/public-api/<route> \
-H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
-d '{ ... }'Clienți API
Un client API reprezintă un sistem extern. Se creează în tabul Clienți API și primește credențiale pentru grant-ul OAuth 2.0 client credentials. Fiecare client are un set de scope-uri și poate apela doar endpoint-urile al căror scope obligatoriu îl deține.
Token-urile sunt JWT semnate de bridge, cu valabilitate scurtă. Când un token expiră, clientul cere unul nou cu credențialele sale.
Limitarea ratei de apeluri
Fiecare client API are propria limită de cereri pe minut, aplicată printr-un token bucket. Limita se stabilește în configurația bridge-ului și se aplică separat fiecărui client.
Jurnalele de apeluri
Fiecare apel este jurnalizat în baza de date a bridge-ului. Jurnalele sunt transmise live în consola din portal, astfel încât administratorii pot urmări apelurile pe măsură ce sosesc. Același jurnal înregistrează și apelurile făcute prin serverul MCP.
Instalare
Rutele bridge-ului sunt în afara căilor API Gateway. Un reverse proxy trimite către bridge căile API-ului public, OAuth și ale bridge-ului, iar restul cererilor către API Gateway. Bridge-ul apelează App Maker Engine direct, prin rețeaua internă.
