# Feature-oriented APIs

DevFeed: [Feature-oriented APIs](<https://devfeed.tech/articles/feature-oriented-apis-20362.md>)

Original publisher: [Read original article](<https://engineering.ziffmedia.com/feature-oriented-apis-f0010d140d3a?source=rss----d6bb34696ef5---4>)

Author: Nathan Petryk

Published: 2017-11-01T15:31:01Z

Content type: tutorial

Language: en

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

Topics: [Clojure](<https://devfeed.tech/topics/clojure.md>), [API](<https://devfeed.tech/topics/api.md>), [Code](<https://devfeed.tech/topics/code.md>), [version](<https://devfeed.tech/topics/version.md>)

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

## AI overview

This article explains how RetailMeNot's Mobile API team evolved a Clojure versioned macro for feature-oriented API development. The approach adds feature rollout support and a feature-flagging system while addressing the limitations of linear, version-based code annotations.

## Source excerpt

In my last post -- Minimally Invasive API Versioning -- I talked about how the Mobile API team at RetailMeNot handles versioning our Clojure APIs using a macro called versioned. This macro alone worked great for over a year, but we needed more. In this post I will cover how we evolved it to help ease our feature rollout process, and how we gained a super-easy feature flagging system basically for free. To recap, the versioned macro introduces a convenient syntax for annotating source code with version-specific information -- things like "this line was added in version 3" or "this line was removed in version 7." We call these annotations version-qualifiers. Initially we had several. some were "binary", like added, removed, only, which let the developer specify code that should or should not exist for a specific application version; and others, like changed, lets the developer specify alternative implementations based on the application version. https://medium.com/media/9c51608aa7d9e2240fdbdcc10742c8d5/href We call these qualifiers collectively linear version-qualifiers, because their functionality is based on the linearity of versions: something like "added in version 2"makes no sense without the assumption that V1 precedes V2, which precedes V3, etc. Like I said, this reasoning got us very far, but it has one major drawback: we typically ship multiple features per version, and when we do encountering this version-specific code would often leave developers wondering, "Why was this change made? Which feature was it a part of?". Furthermore, say a feature slipped and we needed to move it to a later version, we found it difficult to go back through the code base to identify and edit those places only related to that feature. The fundamental problem is that when we annotate code with linear version-qualifiers we imbue that code with version-specific information. Stated another way, these kinds of annotations only let a developer look at the code and answer the question, "Wh