Approccio tecnico
Odoo esteso con un
modulo API REST proprietario.
Web app, mobile app native e portali B2B che parlano con Odoo attraverso un modulo API REST sviluppato internamente. Contratto stabile, autenticazione robusta, versionamento esplicito, audit completo. Niente accrocchi di RPC indovinate alla cieca.
Architettura
Come si incastra tutto,
a colpo d'occhio.
Web app
Vue · Nuxt · React
Mobile native
Swift · Kotlin
Portali B2B
Catalogo · Ordini
Integrazioni
Sistemi terzi · IoT
MODULO API REST
Custom Odoo · Versionato · Auditato
ODOO ERP
PostgreSQL · ORM · Business logic
Principi dell'API
Un modulo pensato per stare in produzione,
non per una demo.
Contratto stabile
Versionato con /v1, /v2. I breaking change non arrivano per caso: deprecation policy chiara, comunicata con anticipo.
Autenticazione robusta
JWT firmati a breve scadenza, refresh token, OAuth2 per i flussi terzi. API key con scope per i server-to-server.
Osservabilità
Log strutturato, correlation ID, metriche per endpoint, alerting su errori e latenze. Chi ha fatto cosa, quando, da dove.
Rate limit & quote
Limiti per client e per utente, quote giornaliere/mensili, risposte 429 corrette con Retry-After. Niente sorprese sul carico.
Permessi chirurgici
ACL per endpoint e per record. Ogni chiamata sa per chi sta operando e cosa può o non può toccare. Isolamento multi-tenant pulito.
Audit trail completo
Ogni operazione tracciata: chi, cosa, quando, payload in/out. Storico consultabile per sicurezza, debug e compliance.
Campione di endpoint
Endpoint reali,
non mock da brochure.
Qualche esempio degli endpoint che tipicamente troviamo nel modulo API dei nostri clienti. Ogni progetto ha il suo set specifico, ma la forma resta consistente: verbi HTTP corretti, risorse chiare, versioning esplicito.
* Gli endpoint reali sono customizzati per ciascun cliente, con schema OpenAPI dedicato.
- GET/api/v1/ordersLista ordini cliente autenticato, con filtri e paginazione
- POST/api/v1/ordersCreazione nuovo ordine, lato client esterno
- GET/api/v1/productsCatalogo visibile al ruolo dell'utente (listini riservati inclusi)
- POST/api/v1/ticketsApertura ticket di supporto dal portale cliente
- GET/api/v1/invoices/:id/pdfDownload PDF fattura (con controllo permesso)
- POST/api/v1/webhooks/:eventWebhook in ingresso da sistemi terzi (firma HMAC)
Stack per tier
Tecnologie usate, senza il marketing.
Client layer
01- Vue 3 / Nuxt 3 per web app e portali B2B
- React / Next.js quando richiesto dallo stack cliente
- Swift (iOS) e Kotlin (Android) per mobile native
- PWA con service worker e offline-first per field service
API layer (modulo custom Odoo)
02- Controller HTTP Odoo con routing REST
- JSON serializer custom, schema Pydantic-like
- JWT auth middleware e rate-limiter Redis-backed
- Logging strutturato + correlation ID end-to-end
Odoo core
03- Modelli ORM, record rules, portal users
- Service-user tecnico dedicato per integrazioni system-to-system
- Cron e server actions per sincronizzazioni asincrone
- Eventi interni che emettono webhook verso sistemi terzi
Infrastruttura
04- PostgreSQL con tuning per workload misto OLTP + read-heavy API
- Redis per cache e rate-limiter
- Nginx reverse proxy con TLS, HTTP/2, response compression
- Docker o deploy bare-metal, CI/CD con pipeline Git
Qualità
Tre cose che non vengono mai saltate.
Security by default
TLS, JWT, HMAC, input validation, rate limit, least privilege. Niente endpoint aperti per comodità.
OpenAPI first
Specifica OpenAPI mantenuta, client SDK generabili automaticamente. Il frontend non indovina i tipi.
Test & CI
Unit + integration + API contract test. Ogni release passa da pipeline Git prima di arrivare in produzione.
Confronto tecnico
Vuoi capire se questo approccio
si applica al tuo contesto?
Una call tecnica di 30 minuti con chi scrive il codice, non con un account manager. Rispondiamo entro 1 giorno lavorativo.