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.
Defining Elements
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 uses to communicate. Imagine trying to use 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 use 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.
API History
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 thoroughly 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 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.
Then, in the 1990s, things really took a leap forward with the introduction of the World Wide Web and web browsers. Things like Hypertext Markup Language (HTML), Hypertext Transfer Protocol Secure (HTTPS), and Javascript enabled secure communication via the web. These connections were the predecessors of the current web API infrastructure of the web.
Breaking It Down
Alright, I got a little more technical than I had hoped in the previous section. Let me back up a step and break this down.
So, in the early days of software development, they gave software 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 programming 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 are 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 involved 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 for 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.
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 funneling 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 possible 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 started fixing Lulu with the behind-the-scenes work first. And central to all of that is our API connections.
Improving Print-on-Demand
The very nature of on-demand printing relies on communication. You (the author) have 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.) that gets the books to your reader.
Within this web of communications are even more connections. Our support team connects with users who need help or experience a printing/shipping issue. Our distribution services pass your book over to online retailers. Our payment services send revenue payments to you.
It’s not a stretch to say that print-on-demand and self-publishing is a products and services businesses 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 Lulu Direct app.
The trade-off is 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 is 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 bookmaker’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 access to print-on-demand and fulfillment
- The Lulu Direct integration for Shopify and WooCommerce for creators and small businesses who need an ecommerce platform but have the means to market and sell on their own
APIs Make It Possible
Offering three distinct ways to access print-on-demand and 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 it.
Closing Thoughts
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 e-commerce-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 bookselling. 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 publish 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.
