If you use the Internet, you’ve used an API. API technology surrounds you. But knowing that this technology is making all kinds of communication possible is different from understanding API coding.
What is an API?
The acronym stands for Application Programming Interface (API). The API offers a clear and concise communication methodology for software, encompassing three main functions:
- Defining elements
- Setting communication rules
- Providing software building-blocks
Defining API without using highly technical terms and phrases is a lot of work. And getting someone who really, deeply understands this programming in a simplified way is a challenge. Breaking it down into the three functions an API fulfills makes this task marginally easier, so let’s cover those first.
In programming, everything is an ‘element.’ From the text on the web page to the images, to the embedded video to the comment thread. Each piece is an element. If you’ve used a drag-and-drop site platform like WordPress or Wix, you’ve experienced working with Elements.
What an API does is define individual elements and their roles universally. Doing so creates a consistent and easy to replicate style. Making it easy to display varied information across different browsers and website experiences. Elements are the basic pieces any website will build from; the API defines how these elements will look, interact, and react.
Setting Communication Rules
Much like defining the Elements, an API will define the rules software use to communicate. Imagine trying using MS Word to write an entire book, then converting all the text to WingDings before printing your book. You’d have a book in a nearly indecipherable language.
An API ensures that all elements are using the same communication format. You can rest assured that your website or software will work properly across a variety of browsers.
Providing Software Building-Blocks
Finally, we need the elements we’ll build software from. By connecting different elements, an API creates the basic ‘building-blocks’ developers used to make new software. And because those building-blocks used standardized elements, the new software avoids a range of communication issues.
Okay, so we’ve got the ability to connect elements, ensure communication between elements, and build out unique elements. The easiest way I’ve found to understand what an API is to think of it as a template. Just like the template you might use when creating a book interior. Ready with pre-defined header and footer space, fonts, text specifications, and page size; the API is a template for web and software development that ensures uniformity.
When Uniformity Is Good
Structures enable innovation and original design. It’s often challenging to appreciate how important an established structure is to creating something new. This is particularly relevant for web-based creators—without holding to the standards your content may not render or function properly on the variety of browsers and operating systems in use today.
In the modern worldwide Web, APIs critically facilitate secure transfers of data and information between servers. All the websites in use today exist on a server somewhere. When you type in a URL or click a link, you’re telling your browser to request information from that site’s server. Communication is simple and organized through a consistent and predictable method.
Most sources point to Library Systems from the 1960s as the first application of API technology. Despite these uses, the modern web API is largely credited to Ray Fieldings and his 2000 dissertation, Architectural Styles and Designs of Network-Based Software Architectures.
“The complexity of modern software systems have necessitated a greater emphasis on componented systems, where the implementation is partitioned into independent components that communicate to perform a desired task.” – Ray Fieldings
Fieldings identifies the key implementation of API technologies for the modern web, but these designs have been widely and thorough used for years prior. In the 1960s and 1970s, computer engineers began to utilize Distributed Computing to achieve more complex tasks. Individual systems, assigned discrete tasks, work together to achieve complex goals .
Distributed computing led to the application based computing in the 1980s, whereby various systems were organized into multi-faceted applications, which could be organized into ‘objects.’ Known as Object Oriented Programming, the idea evolved alongside distributed computing, but took a more firm hold with programming languages like C++ in the 1980s.
Note that both of these programming languages were using the essential elements of an API.
Breaking It Down
Alright, I got a little more technical than I had hoped in the previous section. Let me backup a step and break this down a little.
So, in the early days of software development, they gave programs tasks and computed answers. Then some geniuses realized more complex tasks could be achieved by having each computer do a piece of the larger task. But to achieve a coherent answer from all those discrete systems, the computers had to talk to each other in a simple manner.
Once developers understood how to ensure communication between systems, they started developing programming languages so another developer’s system could use and modify the system they created. This collaborative structure is a fundamental element of the Internet!
Today we have tools like WordPress or Wix; website development tools with a variety of widgets and elements that can be added to a page or a post. Along with the native elements of a website building tool are the massive libraries of third party plugins. Uniform programing language makes this possible.
At the most basic, WordPress is a very user friendly API (yes, that’s an oversimplification, indulge me). The WP interface is a dashboard meant to pull together and connect a variety of tools, widgets, elements, and plugins. You can create a unique and useful webpage, website, blog, or whatever you want to create!
Enabling Development in a Connected World
I hope I’ve helped make plain the basic concepts of Application Program Interfaces. There are far more technical and in-depth takes on this subject, for anyone interest here’s a couple I recommend:
But now I want to transition us to thinking about how we use API connections here at Lulu. One of the earliest connections we facilitated involves online buying and selling, what most now call ecommerce.
Despite many of our best efforts, the trend of adding an “e” to anything that can now be done online or using a device doesn’t seem to fade. C’est la vie.
What is Ecommerce?
Online transactions managed by specialized software companies, Ecommerce is a catchall term of online buying and selling. It’s a transaction without money physically changing hands.
Think about ecommerce considering the information about APIs we now have. A website links you to a shopping cart page with added security, you enter your payment info, and the site connects to your payment method (credit card, PayPal, etc.) and the funds move. API connections make this possible!
Online shopping is possible because of APIs. All the products and services you can purchase online require connections between a web page, a shopping cart, an ecommerce engine, and fulfillment (the software that tells someone in a warehouse to pack up your product or a printer to create the book you ordered).
Lulu, Technology, and You
The historical version of Lulu, circa 2005, had two main goals: To help you publish your book and to act as an ecommerce business with our online store. We are a connection—bringing authors with content into contact with readers and funnelling that connection through a print-on-demand and fulfillment service.
Lulu’s Open API
In late 2017, Lulu made our print-on-demand network available to anyone through our Developer Portal. For many years this wasn’t due to the design of our software and the way we communicated with our printers around the world. But our development staff are ambitious folks.
As of 2016, our software—both what you see on lulu.com and the behind the scenes stuff—was exceedingly outdated and sometimes crumbling around us. As much as software can crumble. I don’t really understand the details, but I certainly heard the phrase spaghetti code more than once.
We’re starting on the behind-the-scenes work first. And central to all of that is our API connections.
The very nature of on-demand printing relies on communication. You (the author) has a file you have to pass to us (the publisher). Then we have to communicate our file and the instructions for printing to our printers. And finally, we have to pass off the finished product (your books) to a fulfillment service (Fedex, USPS, DHL, etc.) who gets the books to you.
Within this web of communications are even more connections. Our support team that connects with users who need help or experienced a printing/shipping issue. Our distribution services that pass your book over to online retailers.
It’s not a stretch to say that print-on-demand and self-publishing is a products and services business built around communications.
So the obvious way to improve print-on-demand is to improve how we communicate.
Why Open Source Web API?
When you make a book and sell it on the Lulu bookstore, you keep 80% of the revenue and we take that other 20%. But if you use our Open API and connect directly to our print network, the relationship changes.
You pay us directly for printing and shipping, but the price you set and charge to your reader is entirely yours.
Here’s a quick scenario to illustrate:
- Total cost (printing and shipping) = $8.00
- Retail price = $18.00
In the scenario above, a sale on the Lulu store would net you $8.00 (80% of the revenue) while a sale through the API would net you $10.00 (100% of the revenue). The difference here is that a reader is buying the book directly from you—from your website or from your Shopify store if you use our xPress App.
The trade off being that you, as the web developer, store owner, and book creator, are responsible for the ecommerce side of the coin. You handle the online shopping, the product page and selling the product to your readers.
Striking a Balance
Print-on-demand has long been a narrow service. And a simple one. A file is provided, and we print a book. That was it.
Over the years, questions about making the process more versatile kept coming up.
- How can we make self-publishing more flexible for authors?
- How can we open the doors for publishers to use print-on-demand?
- And how do we ensure businesses can get the printing and retail tools they need?
After a lot of research and reflection, the obvious answer turned out to be the best. Occam’s razor I suppose.
The solution being to not change the basic model. Instead, we’re just unshackling that service from a single website. Forming a great balance that accommodates (or at least provides the means to accommodate) every book maker’s needs.
- The Lulu Bookstore for authors who create books and want to sell them through established online retailers
- The Open API for businesses and publishers who just need the access to print-on-demand and fulfillment
- The Shopify® App for authors and small businesses who need an ecommerce platform but have the means to market and sell on their own
- Lulu xPress for everyone else—one-off printing, bulk ordering, printing of single orders with no retail needs.
APIs make it Possible
Offering four distinct ways to access print-on-demand and the related services is only possible thanks to our API. The level of communication our software can achieve is unprecedented. The goal is to leverage the versatility to provide more and better options for our users—from authors to publishers to businesses.
What’s most exciting about all of this is that our current platform and options are simply a beginning. With Lulu’s print-on-demand services available through an Open API, you can take that printing option and mold it to your needs! And so can we!
In fact that’s one of the major drivers for Lulu in the coming years. We’ll be taking our print-on-demand API and building out new ways to access and integrate.
But that’s a topic for down the road. Right now, I want to close out this series with a little more on our current offerings.
The Cool and The New
I mentioned at the beginning of this piece we are working diligently on updating and improving the background pieces of Lulu. While that’s not something that shows to most of our users, anyone that has tried out xPress surely noticed the wider variety of product options (Executive 7”x10”!) and a bit lower pricing on some product combinations (a 200 page full color book is around $10 less). Noticing a few of these differences might prompt the question; what’s changed?
Well, we’ve created a new platform that all of our printing will use. Each of our offerings like Lulu xPress and the Shopify® App sends orders to this platform and that’s what our printers connect into. I like to think of it like one of those power stripe surge protects:
Each website or service we create plugs into this surge protector, which plugs into our printers. What’s cool is that you (the author, publisher, business owner, or book creator) can plug in your website or service too!
Understanding how APIs and other forms of software communications function isn’t a requirement to develop a strong and productive web presence in 2019. It hasn’t been for some time actually. Tools like WordPress, Wix, and Shopify provide options for building ecommerce based websites quickly through drag-and-drop interfaces.
You can build a website without ever touching a line of code.
And here at Lulu we want to enable that same level of ease and simplicity for your book selling. Making a web store for your book(s) shouldn’t be a challenge. Neither should the fulfillment process.
We’re working daily to make it easier and more profitable for you to publishing and sell your book. Thanks to the powerful connectivity of API based web platforms, we can offer anyone the ability to publish, print, and prosper around the world.
Paul is the Senior Copywriter at Lulu, writing weekly blog posts and helping guide content for the company’s marketing. When he’s not deeply entrenched in the publishing and print-on-demand world, he likes to hike the scenic North Carolina landscape, read, sample the fanciest micro-brewed beer, and collect fountain pens. Paul is a dog person, but considers himself cat tolerant.