TL;DR

By having your core UI use a public API only, your marketplace company can (a) spend resources in a more effective way, (b) clean up its codebase, (c) improve security by eliminating obscurity and (d) have others find innovative ways to improve the service.

The pitch

 

“Internet marketplaces are eating the world – whether it’s commerce, ride sharing, food delivery or even dog walking – the internet is helping to even the playing field and create a near-perfect economy in many fields.”

This is what the marketplace companies everywhere are pitching – to sellers, to buyers, to VCs and to themselves. We at Gett are happy and proud to join the “marketplace marketplace” – your company may be too.

The bastard children that are private APIs

Whether your marketplace has an app, a website, or both – your UI is using an API to communicate with its backend. And chances are, your API is private – its contract is unpublished and its use prohibited the from public by your terms and conditions.

Yes, you may also have a public API, but do you use it yourself? Most marketplace companies are treating their public API as a skinny little side project, while the heavy-lifting for the “core” UI is done by an internal, complex, feature-rich private API.

Private APIs are embarrassingly messy custom

When you first started development, giving the public access to your internal API seemed crazy. Maybe it was a mess, constantly in flux, evolving rapidly and inelegantly to fit the business needs and changing product requirements.

Remember that once-beautifully-RESTful API endpoint?

POST /api/v1/sessions     // Creates a session and returns its ID.

Somehow, over time, it became decidedly non-RESTful:

POST /api/v8/sessions     // Creates a session and returns its ID,
                          // along with user settings,
                          // active products,
                          // and enabled feature flags.
                          // Disclaimer: Not actual Gett code.

Private APIs are notoriously hard to keep private

You’d be crazy to expose that (theoretical!) “get everything” API call. Your first intention may be trying to control API use. It’s a hard, costly, and most importantly – ultimately impossible task.

Your apps may be obfuscated and protected, but they are essentially living, published documentation to the backend API. If you have a website, it’s trivially transparent to see.

If your service is successful, there is enough motivation to break it; every once in a while a smartass developer – we like to imagine a caped teenager in a dark room – reverse engineers your official app or website. Congratulations! Your first “independent” (or “unauthorized”) version is published. It uses the private API to provide a similar, or “improved” service.

It’s usually a matter of time before those apps are shut down, but others quickly arise again in a kind of cat-and-mouse game – a costly one, with escalating efforts from both sides. Why are you – we – playing it?

 

Let’s discuss some of the traditional arguments for keeping our APIs private.

 

“It’s reducing our development costs”

Documenting, testing and securing an API is expensive. If you have both private and public APIs, you’re probably paying twice – assuming you are documenting, testing and securing your private API. Are you?

Now let’s discuss exposing that messy “get everything” call. Loading multiple resources on a single call is a recurring pattern with apps and websites. REST, a customary first choice for many APIs, tends to be chatty. Issuing many API calls just to load your app is not an option. Consider an alternative like GraphQL, a query language for APIs, started by Facebook:

{
  me {
    name
    settings
    products
    features
  }
}

Other marketplace apps are already using it. With pre-written adapters to existing ORMs and backends, maybe it’s not as expensive to develop and maintain as your old custom, private API. With GraphQL, you could expose your resources to the public and keep your app’s custom data retrieval patterns.

“It’s protecting our IP”

Your private API might seem like an important part of your IP. But for marketplace companies, most of the IP is in the intricacies of the model: the way you design the deals between sellers and buyers, the rating system you employ, how you handle transaction protection, and many more features are the real meat in your IP. Private APIs are not really IP – they are quite easy for your competitors to replicate, and your VCs won’t miss them.

“It’s protecting our users”

You may be concerned about security vulnerabilities in your APIs. Input validation is a simple example – buffer overruns, SQL injections – they need to be addressed. More complex threats are failures to segregate accounts – allowing one user to access another user’s data.

Rate limiting is not technically a security requirement, but it’s also a concern that always comes up.

None of these concerns are exclusive to private APIs. In fact, hiding your API means that it only gets reviewed internally, and chances are it contains more flaws and vulnerabilities than a public well-used API. Private APIs provide little security – they are security by obscurity.

“It’s protecting our brand”

If you publish your API as public, you can expect a variety of client implementations – apps and websites. Some may not be as classy or posh as your own, “core” UI. Some will be down right nasty. Will your brand get trashed by third-party apps from dubious providers? It depends on how you position your public API.

If your brand is perceived as a marketplace (as opposed to a “shop”), apps can be perceived as strictly third-party. Just like Apple’s brand is not tarnished given horrible “contributions” in its app store, you can protect your reputation by separating the marketplace service API from its implementations.

Why go public?

Here are some real-life examples of “unauthorized apps”:

  1. Scan the market continuously for better deals, pushing notifications to sellers/buyers when a good deal appears.
  2. Identify trends in demand and offer sellers deals to “get in the market early”.
  3. Offering customized UX for specific use cases.

These are some great ideas, and “the market” obviously likes them. Yet we, the marketplace companies, are fighting to bring them down. The truth is, after neutralizing the criminal effects, independent apps sometimes add missing features, and provide extra value to customers – supply or demand. Having a public API is like hosting a continuous hackathon for your service.

Now let’s hear that pitch again

Marketplace companies are about “evening the playing field” – that was the pitch. Aren’t we supposed to benefit from “perfect communications between sellers and buyers”? I think it’s time to replace our old private APIs with a safe, simple and complete version, shared by all, and exposed to the market. Not only will we boost innovation, provide better value and improve security – we’ll make a stand and realize our pitch.

Share your thoughts!

What’s your experience with developing a private API? Join the discussion by posting a comment below.