REST vs GraphQL

REST organizza l'API attorno alle risorse: clienti, ordini, prodotti. Ogni risorsa ha un indirizzo (endpoint) e si manipola con i verbi HTTP: GET /clienti/42 legge il cliente, POST /ordini ne crea uno, DELETE /prodotti/7 lo elimina. Se le API sono nuove per te, parti dalla guida Cosa sono le API.

È come un menù a piatti fissi: ogni piatto (endpoint) ha una composizione decisa dallo chef. Ordini "il cliente 42" e ricevi tutti i suoi campi, anche quelli che non ti servivano (over-fetching); se ti serve anche la lista dei suoi ordini, fai una seconda chiamata (under-fetching). In cambio ottieni semplicità totale: URL prevedibili, cache HTTP che funziona da sola, strumenti maturi ovunque. Per le API pubbliche e le integrazioni tra sistemi resta lo standard indiscusso.

I criteri che usiamo nei progetti reali:

• Scegli REST se: l'API è pubblica o consumata da partner (tutti lo conoscono), i flussi sono fissi e prevedibili (integrazione gestionale ↔ e-commerce), la cache HTTP conta (contenuti, cataloghi), il team è piccolo e la semplicità vale oro. In caso di dubbio: REST.
• Scegli GraphQL se: alimenti interfacce ricche che aggregano molti dati (dashboard, app mobili complesse), hai client diversi con esigenze diverse sugli stessi dati, lo schema evolve spesso e vuoi evitare il versionamento.
• Usali insieme se: il progetto è grande — REST verso l'esterno per compatibilità universale, GraphQL all'interno per le proprie interfacce. È un pattern comune e sano.

Nei nostri progetti — web app, gestionali, e-commerce — usiamo REST come base e introduciamo GraphQL solo quando le schermate lo giustificano. E se hai un'API esistente che non sai più come evolvere o mantenere, il servizio di assistenza sito web include anche il check-up delle integrazioni.