# Writing good API wrappers

DevFeed: [Writing good API wrappers](<https://devfeed.tech/articles/writing-good-api-wrappers-21026.md>)

Original publisher: [Read original article](<https://jakeyesbeck.com/2015/05/31/wrapping-apis/>)

Published: 2015-05-31T12:00:00Z

Content type: opinion

Language: en

Sources: [Jake Yesbeck](<https://devfeed.tech/sources/jake-yesbeck.md>)

Topics: [API](<https://devfeed.tech/topics/api.md>), [Library](<https://devfeed.tech/topics/library.md>), [Code](<https://devfeed.tech/topics/code.md>), [HTTP](<https://devfeed.tech/topics/http.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [code](<https://devfeed.tech/tags/code.md>), [developers](<https://devfeed.tech/tags/developers.md>)

## AI overview

The article discusses how to design good API wrappers. It contrasts a minimally abstracted wrapper that remains verbose and exposes request details with an over-abstracted wrapper that hides the underlying API and becomes inflexible. It argues that an effective wrapper should balance terseness with flexibility and provide flexibility, usefulness, and readability.

## Source excerpt

Both in my day job and in my year of commits, I spend a lot of time thinking about APIs. For the uninitiated, an Application Program Interface (API) is an avenue for one piece of software to speak to another. This could be a remote, web-based, HTTP API. Or, the API might be an internal interface for one portion of a software system to talk to another. Designing an API that is simple and maintainable is crucial if it is intended to be used and quickly adopted by colleagues or 3rd party developers. Being one of those 3rd party developers, I find myself using and writing wrappers to these APIs. Here, I will explain what makes a good API wrapper. Let's postulate about some example wrapper designs. The Barely Abstractor The mantra of this design is: "I will take away that annoying HTTP element and you do literally all the rest." We can assume that a library called api_requester exists to wrap our very important 3rd party remote API (Which we will also assume is a RESTful API). If we wanted to retrieve an object our code might look something like: require 'api_requester' params = { object_id: 1 } headers = { 'Content-Type' => 'application/json' } object_wanted = APIWrapper.get( 'relative/path/to/object/', params, headers) # => { big: :hash, of: :attributes} To post an object via this wrapper: require 'api_requester' params = { object_id: 1, object_name: :foo, object_type: :bar, object_description: 'I am an object' } headers = { 'Content-Type' => 'application/json' } APIWrapper.post( 'relative/path/to/object/', params, headers) # => { big: :hash, of: :attributes} So, you get the idea. That idea is verbosity. However, this approach is not all negative. Pros: Resilient to API changes A big problem with wrapping APIs outside of your own control is endpoint churn, change, and deprecation. With such a verbose wrapper, the consumer is in complete control of the request. From URL changes to parameter addition and deletion, a consumer of `api_requester` is able to adapt without up