Sergei
Sergei

Reputation: 1785

REST APIs: Using Ids versus Actual Values in POST/PUT/GET

I am in a process of designing APIs to allow customers to manage their data using POST/PUT/GET.

One of the challenges for the API is that there are number of fields in entities that should have values from predetermined sets. One of the approaches I see is to allow clients to pass IDs for each of the data filed(properties) and have a supplementary method to provide clients with available options for the data fields. So the client interaction with the service will be: Client: GET \Options (returns set of available options for each field) Client: POST \Data (sends the DTO with set of IDs for each property this saves the data to the server)

Another option as I see is to let client to send actual values instead of IDs.

What approach do you recommend? And why?

Upvotes: 1

Views: 190

Answers (1)

supertopi
supertopi

Reputation: 3488

Let clients pass the data as values BUT store the data as a foreign key on your server.

Let's say you design an API for adding cars and the car colour should be a value from a predetermined set.

HTTP requests:

GET cars/1
=> 200 OK
{ id: 1, name: "Ferrari", colour: "Red }


POST cars
{ name: Lamborghini, colour: "Blue" }
=> 201 Created (cars/2)

Database (just an example):

Table [Car]: @ID (Integer) , Name (Varchar) , ColourID (Integer)
Table [Colour] : @ID (Integer), Name(Varchar)

...where the Car.ColourID is a foreign key to your Colour.ID

The advantages are:

  1. The API is easy to use
  2. You still maintain the data constraint from predetermined sets, for example POSTing a car with colour: "Dog" should result in HTTP response with error information (e.g. Invalid colour).

Upvotes: 2

Related Questions