chiave composito per metodi API REST

Question

Sto cercando le migliori pratiche sul design RESTful API per il seguente caso d'uso:

oggetto Dominio veicolo:

class Vehicle { 
    private String vehicleType; 
    private String colour; 
    private String transmission; 
    private String yearOfIssue; 
} 

Un oggetto esempio:

Vehicle = {vehicleType : 'Car', colour : 'Red', transmission : 'Automatic', yearOfIssue : '2008'}; 

In questo modello di dominio, non esiste un identificatore univoco di un singolo campo (ad es. VehicleId), ma piuttosto tutti i campi dell'oggetto insieme costituiscono la chiave primaria (questo vincolo è presente nel livello del database) .

Non abbiamo la flessibilità di modificare questo modello di dominio per aggiungere un identificatore univoco a campo singolo.

Quindi la mia domanda è la seguente: se voglio aggiungere una semplice API REST sopra questo oggetto dominio che fornisce funzionalità semplici per CREARE, AGGIORNARE, CANCELLARE e OTTENERE veicoli, qual è la migliore pratica per gli endpoint PATH per questi metodi?

Seguendo l'esempio di cui sopra, se il modello di dominio dovesse avere un singolo campo identificativo univoco VehicleID, quindi posso immaginare i seguenti endpoint:

GET /vehicles/:vehicleId 
PUT /vehicles/:vehicleId 
DELETE /vehicles/:vehicleId 

Io non sono a conoscenza di un modello che esiste simile a questo per chiavi composite come:

GET /vehicles/:vehicleTypecolourtransmissionyearOfIssue 
GET /vehicles/CarRedAutomatic2008 

sembra errato.

Qualsiasi consiglio su un buon modello da seguire per questo caso d'uso sarebbe molto apprezzato.

Grazie

Answer 1

Come da standard generali REST, ogni endpoint espone una risorsa, e il client possono lavorare su di essi con verbi HTTP. In questo esempio la tua risorsa è veicolo, e il client sta recuperando i dati dal server utilizzando GET. Idealmente, ogni risorsa dovrebbe essere identificata in modo univoco con un'unica chiave (singola).

Ma la risorsa (veicolo) non ha una chiave univoca a valore singolo e non può essere modificata nel sistema! In questo caso si può ancora fare la chiamata GET con tutti i parametri necessari per identificare la risorsa, come tutte le altre chiamate HTTP standard, come

GET /vehicles?type=Car&color=Red&transmission=Automatic&manufactureYear=2008 

La tecnologia/piattaforma che si sta utilizzando, se questo permette di fare percorsi personalizzati per la vostra metodo, è possibile creare un percorso personalizzato qualcosa come

new route("/vehicles/{type}/{color}/{transmission}/{manufactureYear}") 

E chiamare il servizio come

GET /vehicles/Car/Red/Automatic/2008 

La cosa buona di questo è, il vostro uri diventa più corta . Ma d'altra parte [1] Per tutti i metodi/risorse di questo tipo, dovrai creare percorsi personalizzati, e [2] questo uri non ha molto senso se non conosci il metodo e il percorso specifici.