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

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:

  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
  json = JSON.parse(our_names)
  • Get the first person’s firstname. Ruby counts from 0, not 1!
  => "Emma"
  • Get the second person’s firstname
    => David
  • Get each bit of the JSON data…
      json.each do |person|
  • … and print the firstname and last name, with a space in the middle.
      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, Bibliocloud, 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 Bibliocloud 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. Bibliocloud 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 Bibliocloud, 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 my own publishing ERP solution Bibliocloud 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.


    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Learning how to code, the long way around
  4. A manifesto for skills
  5. It's us in the industry who need to be able to code
  6. Menial publishing jobs are destroying our future
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. And now we are five
  12. Prizes galore
  13. Sara O'Connor to join the team!
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. What publishers need to know about Ruby on Rails
  27. How APIs can make publishing more efficient
  28. A day in the life of a programmer
  29. A publisher’s guide to APIs
  30. eCommerce

  31. Don’t outsource your publishing business away
  32. Inbound marketing
  33. Who has the balance of power over data?
  34. To go direct, publishers must mean business
  35. Why publishers must use direct sales
  36. The business case for going direct
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. BIC, Thema and artificial intelligence...
  42. Three ways to do more with ONIX
  43. How to create a catalogue automatically using ONIX and InDesign
  44. A non-technical, beginners’ guide to ONIX for Books
  45. ONIX Changes
  46. Skills

  47. A taste of code
  48. Mechanical sympathy
  49. Publishers can learn a few things from programmers
  50. Embrace the code
  51. Strategy

  52. A company of one's own.
  53. Responsibility, Authority, Capability
  54. Five things I've learned since moving into enterprise product management
  55. The search for publishing's holy grails
  56. Sometimes, size matters
  57. Managing expectations
  58. Rejuvenation
  59. Decisions, decisions
  60. The real price of a strategy shift
  61. Why ‘easy’ publishing solutions hardly ever are
  62. Technical debt
  63. Start with Why – How to refine your publishing mission
  64. The right tool for the job
  65. No computer system can fix a broken publisher
  66. Creative industries and the division of labour