Mix REST API plurale e singolare per risorse diverse?

Question

La forma plurale per REST api è più naturale e più usata per es. /api/users o api/users/123.

Ma per alcune risorse non è ad esempio naturale:

• /api/login - il login esattamente un utente
• /api/profile - ottenere profilo di utente connesso

queste risorse non saranno utilizzati per ulteriori quell'oggetto/modello nella mia app.

D'altra parte, ho letto che mescolare la forma plurale e singolare nei nomi di risorse non è una buona pratica (http://pages.apigee.com/web-api-design-ebook.html).

Quindi ritengo che cosa fare:

1. uso singolare per tutti plurale
2. uso per tutti (con alcune forme stupide come /api/logins)
3. di essere incoerente e utilizzare il plurale per quasi tutte le risorse si aspettano alcune risorse speciali come /api/login o /api/profile che vengono sempre utilizzate con un oggetto/modello.

Qual è l'approccio migliore?

Answer 1

Non ci sono linee guida rigide per definire un'API RESTful, ma quello che ho letto di più è che il buon senso dovrebbe avere la meglio.

Pertanto, l'opzione 3:

di essere incoerente e usare il plurale per quasi tutte le risorse si aspettano alcune risorse speciali come/api/login o/api/profilo che ha sempre utilizzato con un oggetto/modello.

è il più logico. Dovresti essere sempre in grado di indovinare l'URL quando pensi "Ho bisogno della risorsa X, come sarebbe questo URL"?

Answer 2

REST (trasferimento stato di stato) è fondamentalmente per una singola entità e per eseguire CRUD su di esso. Quindi usare il singolare ha più senso per me. Ma nel caso in cui quando hai bisogno di ottenere la lista allora plurale ha un senso. Per esempio:

si vuole ottenere un utente quindi avere/api/user/{id}

Ma se si vuole ottenere l'elenco degli utenti poi hanno/API/utenti

Answer 3

Sono Non sto dicendo che preferisco i plurali, ma se stai usando plurali potresti riconciliare i tuoi singolari speciali in questo modo:

GET /api/forms/login è il modulo di login HTML. Utilizzando questa prospettiva, login è un ID di un solo modulo in una raccolta di moduli.

POST /api/forms/login è il modulo di accesso inviato.

GET /api/users/{id}/profile recupera il profilo dell'utente indicato.Questo funziona per un sacco di casi, ma non funziona per i siti di anonimato in cui l'identità dell'utente deve rimanere nascosta anche mentre guarda il loro profilo, che potrebbe lasciare fuori l'ID utente e il nome reale.

GET /api/profiles/{id} disaccoppia l'entità profilo dall'ID utente e funzionerebbe per un sito di anonimato.

In alternativa, è possibile scrivere GET /api/users/current/profile o GET /api/sessions/current/profile che omette un ID specifico come nel proprio post poiché il server risponderà con il contenuto rilevante per l'utente corrente.

Answer 4

Quello che ho visto in alcuni progetti che ho lavorato su questi anni è che gli sguardi singolari più amichevole per la maggior parte delle operazioni comuni, si può avere ad esempio i seguenti punti finali per l'utente risorsa:

GET /user --> retrieves all users 
GET /user/{id} --> retrieves a user with the given id 
POST /user --> inserts a new user (the user object will come in the request body) 
PUT /user/{id} --> updates a user with the given id (the user object will come in the request body) 
DELETE /user/{id} --> deletes the user with the given id 

queste sono operazioni comuni, quando si dispone di massa/aggiornare/cancellare le operazioni di inserimento, allora dovrebbe essere meglio usare il plurale

POST /users (the user objects will come in the request body) 
PUT /users/{listOfIds} (the user objects will come in the request body) 
DELETE /users/{listOfIds} 

GET/utente e ottenere/utenti sarebbero sinonimi, questi due avrebbero accettato i parametri di query per perfezionare i risultati, per es

GET /users?status=active