Technology

Follow Us

What’s in a Name? For APIs, A Lot

APIs (application programming interfaces) are all the rage these days. There’s an API for just about everything.

Why? Because APIs are the connectors that make software useful. One software product by itself can be great, but when it connects with others – especially ones that provide complimentary functions – you get a combinatorial effect that means the API-connected network of software is greater than sum of its parts.

At Ipreo, our vision is to power the networks that connect capital to ideas.information security, technology, tech blog, Ipreo, data, API, fraud, fintech

That word “connect” is in there, and it’s super important. For a modern IPO, it’s not unusual to have hundreds of separate financial institutions collaborating to bring the new security to market. Those institutions each have many people working diligently to make the deal a success.

Their success is driven, to a large degree, on how well they can collaborate. Does everyone get information quickly? Is the information well-structured and complete? Are reactions and follow-ups distributed easily to all parties? There are tons of connectivity aspects, and if the connections are good, happy people can ring a bell to open trading on a stock exchange one day.

You can probably guess where I’m going with this.

Financial transactions like IPOs need good APIs, because APIs enable connections. APIs connect capital to ideas. Ipreo has established a team to focus on these connections. To keep things simple, we’re calling it Ipreo API.

Background

Ipreo recently celebrated its 10th anniversary as a combined company. Some groups within Ipreo trace their lineage back further than that, joining Ipreo through acquisition. Some are even from the nineteen-hundreds!

Over the years, Ipreo’s various product teams built various forms of “software integrations” to enable clients to programmatically interact with their otherwise human-oriented products, like web apps. Some of the more recent integrations are RESTful APIs, and some of the older ones are SOAP web services.  Aside: you can approximate the vintage of an engineer or tech manager by whether they call them “web services” or “APIs”. Some are not really either of these, and just exchange data over HTTP using custom semantics that probably made a lot of sense at the time.

While this works for individual products, it’s difficult for our clients to create integrations that span multiple Ipreo products. For starters, each integration has different hosts, with different semantics. One integration may use the term “transaction” and another may use the term “deal” – even though in the real world those mean pretty much the same thing.

Given this, the API team established these primary goals for Ipreo API:

  1. Clients will be able to access Ipreo’s API through a single host that exposes consistent semantics
  2. We should not rebuild the bulk of our existing software integrations

At first glance, these two goals seem in conflict with each other. How can we provide a consistent API experience on top of varied legacy software integrations?

Our answer is routing.

Routing

Routing is the process of directing incoming requests to a different place, and returning the response back. It’s pretty simple when you think about it. If the conversation was amongst humans, we could think of it going something like this:

Client: Hey, I’d like information on Snap’s IPO.
Router (to Client): Ok, coming right up!
Router (to IPO Service): Hey, can you give me information on Snap’s IPO?
IPO Service: Sure! Here it is: 101010100101000101001010…
Router (to IPO Service): Thanks! You’re the best.
IPO Service: Any time!
Router (to Client): Here you go! 101010100101000101001010…

Imagine the Client is an Ipreo subscriber’s computer, and the Router is Ipreo API, and the IPO Service is an existing Ipreo software integration service that focuses on IPOs. That’s how it works!

Ipreo API acts as an API router. It accepts incoming requests, like this:

GET https://api.ipreo.com/IPOs/SNAP

It then forwards that request to the appropriate backend service, like this:

GET https://deals.ipreo.com/equity/summary/SNAP

It gets a response from the backend, which might look like this JSON data:

{
  “issuer”: “Snap, Inc”,
  “symbol”: “SNAP”,
  “date”: “2017-03-02”,
  “exchange”: “NYSE”,
  “shares”: 200000000,
  “price”: 17.0
}

Finally, Ipreo API sends this JSON data back to the client.

This is the simplest case, and of course there are more complex cases. But it’s remarkably powerful since it allows us to create a consistent URL structure for Ipreo API without changing backend services. We can avoid name collisions by making sure that the routes are unique. We can normalize synonyms.

In short, we can name things correctly. And that’s a good thing for an API.

Stay tuned for more on Ipreo API. And oh yeah, we’re hiring!

Jeff Sternberg

Jeff Sternberg is Ipreo’s Director of Data Engineering. He works with Ipreo’s content and API teams. Jeff usually writes blog posts in SQL first, then translates them to English