Geek Answers Handbook

API versioning and data storage

When exposing different versions of the API, how do you handle storing and retrieving data that may have different structures?

Say we have two versions of the API; V1 and V2. V1 and V2 have a POST endpoint in ' https://api.com/message ', which will create a message in the database based on the transmitted data, for example:

{
    DOB: '2014-12-01'
}

In V1, the required data is different from V2, because in V2 we decided to change the DOB from the string with the format "YYYY-MM-DD" to a whole timestamp, for example. 1284723728323

In this case, when we save data from a call using API V2, the DOB field will be integer, but when saving from a call to V1, it will be a string in a completely different format.

With each iteration of the API, we can change many aspects of the underlying data. Calling older versions of the API will cause the saved data to be invalid for other versions of the API.

Is there an elegant way to deal with different versions of the API that require data in different formats / structures?

+4
source share
2 answers

Which view the version of the API accepts should not be related to how the data is stored in the backend. I would do this:

  • The V1 API accepts and creates strings YYYY-MM-DDas dates.
  • The V2 API accepts and produces 1284723728323integers as dates.
  • Both versions of the API map their format to and from the common storage type.
  • (, int), .
+3

, API, -, interface (, Java.)

, API , , -.

, , MyWebServiceInterfaceV1.

( , " " ), , , , , -. , .

, MyWebServiceInterfaceV2.

, , , , , .

, V1 V2 , , reverse: integer-date to string-date. , ; , , , . , , .

N, (N-)/2 , , N , , , .

, , .

+5

More articles:


All Articles