Evolution Strategy

The evolution strategy of the API is gracefull degradation over versioning.

This means you will not see /v2/ in the URLs. Instead you (the client) will have to update your code according to the non-breaking changes implemented in the API as it evolves.

Hence it is important to be conscious of the definitions of breaking and non-breaking changes:

Breaking change:

A breaking change is a change in API semantics or format.

Let's say a color element initially contains data on the exterior color of a car, but changes so that is describes the interior color of the car.

Non-breaking change:

A non-breaking change is removing and adding data.

Let's say again the color element contains data on the exterior color of a car. Later, an interior-color element is added, holding data on interior color off course. Also, a field may simply disappear. It is important to recognize that this is not a bug but simply a result of business rules evolving. As you might have noticed, there is an important distinction between semantics/formats and data

Changes in FINN extentions:

When parsing the feed or entry, all elements defined in the finn:adata element are subject to change. You should parse it in a fail-safe manner. Fields may be removed or added (non-breaking change). This is why the name of finn:field defines name as an attribute, instead of being reliant on an XML schema. So if a price is being changed from a number to a string, this will be added as a new field, and the old one will eventually be removed. This is to prevent versioning of the API, making both server and clients support multiple versions. Check out the model -attribute of the finn:field to see what to expect from the ad data.

Here's an example of an ad model describing the data from a car-used-sale ad:

   "description":"Number of seats",
© 1996 - 2022 FINN.no AS