Endpoint API: Le Regole per una Struttura Chiara e Coerente
Quando si tratta di denominare gli endpoint delle tue #API, seguire le migliori pratiche è fondamentale per garantire che la tua API sia intuitiva, coerente e facile da usare. Ecco alcune linee guida ed esempi che ti aiuteranno a denominare efficacemente i tuoi endpoint API:
- Utilizza sostantivi per i nomi delle risorse. Gli endpoint devono rappresentare risorse (sostantivi) piuttosto che azioni (verbi). Ad esempio, utilizza
/users
invece di/getUsers
. - Usa nomi al plurale per le collezioni. Quando fai riferimento a una collezione di risorse, usa sostantivi al plurale (es.
/users
). Per una singola risorsa, usa il sostantivo al singolare con il suo identificatore (es./users/{id}
). - Sfrutta i metodi HTTP per definire le azioni:
- GET: Recupera una risorsa o una collezione di risorse (es.
GET /users
,GET /users/{id}
). - POST: Crea una nuova risorsa (es.
POST /users
). - PUT o PATCH: Aggiorna una risorsa esistente. Usa
PUT
per aggiornamenti completi ePATCH
per aggiornamenti parziali (es.PATCH /users/{id}
per aggiornare parzialmente un utente). - DELETE: Elimina una risorsa (es.
DELETE /users/{id}
).
- GET: Recupera una risorsa o una collezione di risorse (es.
- Struttura gerarchica. Usa una gerarchia chiara e logica per rappresentare le relazioni tra risorse (es.
/users/{id}/posts
per rappresentare i post di un utente specifico). - Usa convenzioni di denominazione coerenti. Attieniti a una convenzione di denominazione coerente, come
snake_case
okebab-case
, e mantienila in tutta l'API (es./user_profiles
o/user-profiles
). - Evita caratteri speciali e spazi. Usa trattini (``) per separare le parole nei percorsi URL, evitando spazi o underscore (es.
/user-profiles
anziché/user_profiles
). - Mantieni il tutto semplice e intuitivo. I nomi devono essere facili da comprendere e ricordare. Evita terminologie complesse o eccessivamente tecniche.
- Versiona la tua API. Includi la versione nei percorsi degli endpoint per consentire modifiche future senza rompere le versioni attuali (es.
/v1/users
). - Descrivi le azioni con parametri di query. Invece di utilizzare verbi nei percorsi degli endpoint, usa parametri di query per filtrare, ordinare o cercare (es.
GET /users?status=active
).
Esempi di endpoint API ben strutturati
Ecco alcuni esempi di endpoint ben strutturati che seguono queste migliori pratiche:
Gestione utenti:
GET /v1/users
– Recupera una lista di utenti.GET /v1/users/{id}
– Recupera un utente specifico tramite ID.POST /v1/users
– Crea un nuovo utente.PUT /v1/users/{id}
– Aggiorna le informazioni di un utente.DELETE /v1/users/{id}
– Elimina un utente.
Autenticazione:
POST /v1/auth/login
– Login utente.POST /v1/auth/register
– Registrazione utente.POST /v1/auth/logout
– Logout utente.
Relazioni tra risorse:
GET /v1/users/{id}/posts
– Recupera i post creati da un utente specifico.POST /v1/users/{id}/posts
– Crea un nuovo post per un utente specifico.
Paginazione e filtraggio:
GET /v1/users?page=2&limit=10
– Paginazione con 10 utenti per pagina.GET /v1/posts?sort=desc&category=tech
– Recupera i post ordinati per data in ordine decrescente e filtrati per categoria.
Operazioni complesse con nomi chiari:
PATCH /v1/orders/{id}/status
– Aggiorna lo stato di un ordine (ad esempio, "annullato" o "completato"). Evita l’uso di verbi come "cancel" nel percorso dell'endpoint e preferisci un sostantivo o un nome che descriva lo stato finale della risorsa, come/orders/{id}/cancelled
.PUT /v1/users/{id}/password
– Aggiorna la password di un utente.
Gestione degli errori e degli stati:
GET /v1/orders?status=pending
– Recupera gli ordini con stato "in attesa".
Conclusione
Seguendo queste pratiche, puoi creare un'API chiara, coerente e facile da usare che sarà intuitiva per gli sviluppatori. Le convenzioni di denominazione sono fondamentali nella progettazione delle API, poiché forniscono chiarezza e riducono la confusione, rendendo più semplice per gli sviluppatori comprendere e interagire con la tua API.
Considerazioni aggiuntive
Ricorda che, sebbene REST sia una pratica comune e molto diffusa, non deve essere vista come un dogma. È solo uno dei tanti approcci disponibili per costruire API. In alcuni casi, potrebbe essere utile esplorare altre soluzioni, come GraphQL, che forniscono maggiore flessibilità quando le esigenze diventano più complesse.