Composite key for REST API methods

Question

I'm looking for the best practices on RESTful API design for the following use case:

Domain Object Vehicle:

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

An example object:

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

In this domain model, there is no single field unique identifier (e.g. vehicleId), but rather all fields of the object together form the primary key (this constraint is there in the database layer).

We have no flexibility to alter this domain model to add a single field unique identifier.

So my question is as follows - If I want to add a simple REST API on top of this domain object that provides simple functionality to CREATE, UPDATE, DELETE and GET Vehicles, what is the best practice for the PATH endpoints for these methods?

Following the above example, if the domain model were to have a single field unique identifier vehicleId, then I can imagine the following endpoints:

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

I'm not aware of a pattern that exists similar to this for composite keys as:

GET /vehicles/:vehicleTypecolourtransmissionyearOfIssue GET /vehicles/CarRedAutomatic2008 

seems incorrect.

Any advice on a good pattern to follow for this use case would be greatly appreciated.

Thanks

Answer 1

As per general REST standards, each endpoint exposes a resource, and client can work on them with http verbs. In this example your resource is vehicle, and client is fetching data from server using GET. Ideally, each resource should be uniquely identified with a unique (single) key.

But your resource (vehicle) does not have a single value unique key, and it cannot be changed in the system! In this case you can still make the GET call with all required parameters to identify the resource, like any other standard http calls, like

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

The technology/platform you are using, if that allows making custom routes for your method, you can create a custom route something like

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

And call your service as

GET /vehicles/Car/Red/Automatic/2008 

The good thing about this is, your uri becomes shorter. But on the other hand [1] For all methods/resources of this type, you'll have to create custom routes, and [2] this uri doesn't make much sense unless you have knowledge of the specific method and route.