# Minimally Invasive API Versioning

DevFeed: [Minimally Invasive API Versioning](<https://devfeed.tech/articles/minimally-invasive-api-versioning-20364.md>)

Original publisher: [Read original article](<https://engineering.ziffmedia.com/minimally-invasive-api-versioning-de5d85ea96d7?source=rss----d6bb34696ef5---4>)

Author: Nathan Petryk

Published: 2017-10-18T15:31:01Z

Content type: article

Language: en

Sources: [RetailMeNot](<https://devfeed.tech/sources/retailmenot.md>)

Topics: [API](<https://devfeed.tech/topics/api.md>), [Clojure](<https://devfeed.tech/topics/clojure.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [function](<https://devfeed.tech/topics/function.md>), [Code](<https://devfeed.tech/topics/code.md>), [JSON](<https://devfeed.tech/topics/json.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [clojure](<https://devfeed.tech/tags/clojure.md>), [code](<https://devfeed.tech/tags/code.md>), [function](<https://devfeed.tech/tags/function.md>), [json](<https://devfeed.tech/tags/json.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [mobile-app-development](<https://devfeed.tech/tags/mobile-app-development.md>), [programming](<https://devfeed.tech/tags/programming.md>), [versioning](<https://devfeed.tech/tags/versioning.md>)

## AI overview

This article describes how RetailMeNot used Clojure to support old mobile API and app versions. It introduces an OfferCard function that returns a JSON map, then discusses copy-and-modify and call-and-mutate approaches for evolving the function while maintaining compatibility.

## Source excerpt

One of the challenges in developing an API for mobile apps is that there is not both a pleasant and reliable way of forcing them to upgrade. This means that in some cases your API needs to support apps that are several years old. The mobile API for RetailMeNot is no exception. This post walks through one of the ways that we've leveraged Clojure to make supporting old API versions, and thus old app versions, significantly easier. First, I will introduce you to a function that builds a portion of our response. https://medium.com/media/93494e2cb8cdc53206a5fdb83ec5e0f8/href This is a simple function that builds the meat of an "offer card." The function is called "OfferCard"; it has three arguments -- "image," "title" and "description" -- and it returns a JSON map with its arguments embedded in it at certain locations. The OfferCard is ubiquitous in our app, and many attributes have been added and removed over time to support changes to the mobile apps over time. Two traditional ways for iterating on a function like this exist: The first way is what I'll call copy-and-modify. This involves simply copying the source code, picking a new name for the function and then making whatever changes are necessary to fulfill your requirements (and, of course, making sure the caller picks the correct version to call): https://medium.com/media/072cb308f9cf0cdac75663fef1cd1fff/href You're probably allergic to copy-pasted code, and rightly so; copy-pasted code, while not always a bad thing, may subtly change over time, and in general just creates another chunk of code that must be maintained. The alternative is for a new, second function to call the old function, and then mutate its return value to fulfill the requirements. I'll call this the call-and-mutate method. https://medium.com/media/bd0884d2eb4b390cce0b3ae0c43b2fbb/href This technique also has some tradeoffs. One nice aspect is that modifications to the original OfferCard function will automatically be incorporated in the OfferCar