How APIs can make publishing more efficient

As a rule, application programming interfaces, or APIs, aren’t easy to talk about.

For instance, you can’t have a debate about whether or not APIs are a good idea. That would be like arguing over whether the Internet is a good idea.

Instead, it’s easier to talk about what a modern API actually is. We in the publishing world need to get in the habit of having that conversation more regularly, since APIs are already helping plenty of publishers improve data integrity and become more efficient, and they could mean a great deal more for the future of the book trade.

To that end, a quick primer: Not so long ago, getting web services (websites, in common parlance) to talk to one another was a fairly tricky ordeal. The main protocol, called SOAP, established a way of passing XML over HTTP, but it was complex and difficult to implement and was liable to break if anything on either side of the data exchange changed. Nowadays, any web service worth its salt exposes some of its data using a RESTful API. (REST is the architectural style upon which the web itself is built.)

Modern, RESTful APIs tend to send data in what’s known as the JSON format, which is a lovely thing. JSON data is laid out in a structured way that both humans and computers can read. This is how I’d display my own and my colleague’s names:

1
2
3
4
5
6
7
8
  our_names = '[{"firstname": "Emma",
                "lastname" : "Barnes"},
               {"firstname": "David",
                "lastname" :"Aldridge"},
               {"firstname": "Rob",
                "lastname" :"Jones"
               }]'

Curly braces and square brackets keep the data in a structured order. If I want to get at the data, I can do something like this:

Use the Ruby JSON gem to parse data in the JSON format

1
  json = JSON.parse(our_names)

Get the first person’s firstname. Ruby counts from 0, not 1!

1
2
  json[0]["firstname"]
  => "Emma"

Get the second person’s firstname

1
2
  json[1][firstname]
=> David

Get each bit of the JSON data…

1
  json.each do |person|

… and print the firstname and last name, with a space in the middle.

1
2
  puts person['firstname'] + ' ' + person['lastname']
=> Emma Barnes, David Aldridge, Rob Jones

Modern web services make data available in that JSON format, at a perfectly ordinary web URL. And if you know some rudimentary programming, it’s straightforward to go to that URL, authenticate with your username and password and read the data. If the application’s API allows it, you can also send data. In practical terms, that means that even novice programmers can get computers to share information.

This has terrific, and by now well-known, implications for digital publishers. Take our metadata web app, Consonance, which sends its data to the e-commerce platform Shopify via an API. In the same vein, publishers can write their own web apps and get them to ask Consonance for up-to-date metadata to populate them.

There are quite a few well-known APIs already in existence and freely available for use by the book trade. Consonance grabs book reviews and ratings from Goodreads’s API. It collects and stores tweets that include authors’ names and book titles from Twitter. It harvests book information and review ratings from Google Books’s API. It also grabs the current data from Amazon’s API for all of a publisher’s titles and compares them to the data held in Consonance, flagging any mismatches.

Can you imagine the time-saving potential of that automatic checking service, the improved quality of data provision—and the knock-on effect of being able to sell more books as a result? These are just a few of the immediate benefits APIs can bring to a digital publishing business.

And as we look ahead to an industry increasingly driven by web services, it’s easy to see that the overarching issue becomes figuring out how these services integrate with each other.

Using a web service to store your metadata is one thing; getting it to populate your e-commerce website and rights platform, grab sales data and send orders directly to printers, partners and other platforms is quite another.

As I wandered around the London Book Fair’s tech area this week, I saw no end of interesting web applications, all of which could provide value to publishers. But the really useful ones will be those that play nicely with the other services you use. The content management system Librios, the content solution IDM, the semantic publishing platform Ontotext, the social DRM service BooXtream, the Edelweiss platform and of course Consonance all have APIs—which means they can be configured to work as part of an ecosystem, with data being transferred programmatically between them to allow publishers to get the most out of their investments without adding administrative overhead.

From a publishers’ point of view, any efficiency gains from new web services are lost by repetitive web processes. If you have to type book data manually into your ebook platform, and then into your metadata system, and then into a rights marketplace, and then into retailer web forms and so on, it’s no better than the bad old days. APIs let us enter data in just once and get the computers to do the boring bit of sharing it around. And then things start look a lot more productive.

So when you’re considering your options from the plethora of web services coming to market, ask web service developers to show you their well-documented APIs as well as the functionality of their products. You’ll be headed toward a more strategically sound, better integrated investment.

(I originally wrote this article about APIs for DBW in February 2015.)

Are your current systems sabotaging your growth ambitions? Are you hungry to implement new business models, but concerned you lack the strong administrative foundations needed for innovation?

We're always amazed at how resigned publishers have had to become to the low bar in publishing management systems. Demand more.