title: Composite key for REST API methods
body: <p>I'm looking for the best practices on RESTful API design for the following use case:</p>
  
  <p>Domain Object Vehicle:</p>
  
  <pre><code>class Vehicle {
      private String vehicleType;
      private String colour;
      private String transmission;
      private String yearOfIssue;
  }
  </code></pre>
  
  <p>An example object:</p>
  
  <pre><code>Vehicle = {vehicleType : 'Car', colour : 'Red', transmission : 'Automatic', yearOfIssue : '2008'};
  </code></pre>
  
  <p>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).</p>
  
  <p>We have no flexibility to alter this domain model to add a single field unique identifier.  </p>
  
  <p>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?</p>
  
  <p>Following the above example, if the domain model were to have a single field unique identifier vehicleId, then I can imagine the following endpoints:</p>
  
  <pre><code>GET /vehicles/:vehicleId
  PUT /vehicles/:vehicleId
  DELETE /vehicles/:vehicleId
  </code></pre>
  
  <p>I'm not aware of a pattern that exists similar to this for composite keys as:</p>
  
  <pre><code>GET /vehicles/:vehicleTypecolourtransmissionyearOfIssue
  GET /vehicles/CarRedAutomatic2008
  </code></pre>
  
  <p>seems incorrect.</p>
  
  <p>Any advice on a good pattern to follow for this use case would be greatly appreciated.</p>
  
  <p>Thanks</p>