Ho visto le API di Facebook che a volte iniziano con ID risorsa. Inoltre, se l'URI è per un processo aziendale rispetto a una risorsa a grana fine, sarebbe accettabile avviare l'endpoint con un ID, ad es.
/{fine-grained-id}/businessProcess
Quindi l'ID non rappresenta un elemento in un elenco di processi aziendali, ma è l'ID di risorsa chiave necessario per il processo.
Roy Fielding ha introdotto REST - link - e non credo che ci sia qualsiasi cosa nella sua tesi che prescrive un particolare schema URI. Finché il tuo schema è coerente, dovrebbe andare bene. Sarebbe anche consigliabile se ha senso agli utenti spiegare perché la struttura esiste, anche se non è un'API pubblica.
Un principio chiave delle interfacce RESTful è che: identificano le informazioni.
Ad esempio, se volessi LEGGERE informazioni - ad es. Utente 123, quindi dovresti inviare una richiesta GET con l'id come 123.
Dove l'ID dell'utente si trova, all'interno dell'URL, è irrilevante. Generalmente la maggior parte dei percorsi specifica l'ID alla fine dell'URL. Ma puoi certamente specificarlo dove vuoi. Non hai nemmeno bisogno del protocollo http per creare un'interfaccia riposante. Fintanto che puoi identificare la risorsa - sia all'inizio dell'uri o alla fine - non importa.
/{fine-grained-id}/businessProcess
Non ho familiarità con l'API di Facebook, ma dovresti evitare di inserire azioni o processi nei tuoi URL se l'intento è di chiamare quell'azione facendo una richiesta a quell'URL. Ad esempio questo è sbagliato
GET /infrastructure/database/reshard
Invece, il cliente deve mettere le risorse database nello stato resharding e poi dire al server che è il nuovo stato del database.
PUT /infrastructure/database
{state: resharding}
Le sole azioni che puoi eseguire su una risorsa sono definite nelle specifiche HTTP (GET, POST, PUT, DELETE ecc.). HTTP riguarda il trasferimento di stato. Il client non chiede al server di eseguire un'azione su una risorsa che ha (client: per favore riscrivi il database ).
Invece, cambia lo stato di una risorsa (che ricorda un concetto astratto) e poi usa le semplici azioni HTTP per far sapere al server che ha aggiornato questa risorsa e che il server deve essere sincronizzato (client: Ho messo il database in questo nuovo stato di resharding, aggiorna la tua rappresentazione di questa risorsa )
Il database fisico viene fisicamente risarcito come effetto collaterale del server che sincronizza il suo stato della risorsa con lo stato del client.
Leggi altre domande sui tag rest