Chapter 3. API First

This chapter covers

• Code consistency
• Feature equality
• Increased velocity
• External/open versus internal
• Examples of API First development

When you’re setting up an API, the vision for the entire platform is quite important, from determining the business value through structure and design decisions. I’m going to step back for a moment from the practical description of APIs in order to talk about an overarching model that is generally superior to the old model of creating APIs in parallel with the main product.

Previous models for product lines with multiple different interfaces, such as mobile or integration, were created so that each of the integration points available for the different client use cases were built independently. This generally led to unfortunate consequences—APIs that were creating code already written for the main product, APIs that were perennially behind in features and functions, and a great deal of technical debt because each change to the system needed to be pulled into each type of client.

API First does what it says. Instead of product first, the API First model describes a model where the back end interfaces only with the API, and all products—the main front-end website, mobile integrations, and other integrations—interface with the API itself.

3.1. Why choose API First?

API First makes a lot of sense for any company. As soon as you have more than one product, you should have a layer to protect the clients from changes on the server. Your website and mobile application should both be able to get information from the system. A well-documented interface into the system, crafted with specific use cases in mind, allows you the freedom to change things around on the back end, as long as the interface doesn’t change. You can switch out the database, add scaling, or refactor your back end entirely as long as you adhere to the documented interface. Integrated testing is easier, and the main products running on the API will, by their nature, test the integrity of the system on a regular basis through the daily use of that platform.

To understand why API First is a good idea, you first have to understand what the existing model looks like. Various architecture models are available that support web API platforms, but many existing APIs are created using a pattern where the API accesses the back end directly in parallel with the main product. This means that if you want to make new products, you have to either write more systems that access the back end or extend the API so that it supports both alternative products. Additionally, an API is frequently considered to be an “extra, nice to have” product rather than an important member of the product ecosystem. This attitude creates problems because companies are frequently focused on revenue-producing products; if there’s no understood value for the API, it will likely suffer from a lack of needed resources.

3.1.1. APIs as side products

Figure 3.1 shows an example of the “usual” setup for APIs. As you can see, the API is separate from the main product, and even if all secondary products, such as mobile or partner integrations, run off of the API, a mismatch can exist between the features and functionality available in the main product and API-driven products. For instance, the main product may get a new activity feed, but because that coding is happening within the main product, it doesn’t appear in the API (or as an extension in the mobile application or partner integrations). Keeping everything entirely consistent—from features and object structure—is theoretically doable, but it’s a lot more work than restructuring the infrastructure to treat the API as a piece of core technology for the system. The back-end system is the critical component for both the APIs and the main product, and separating out the clients in this way makes it harder to triage and fix problems that might occur in the product or the API. Keeping everything in the same pipeline—from back end, through the API, to the product lines, including the main web product, the mobile clients, and APIs for partner integration—helps ensure consistency and reliability, and as your product grows, it makes scaling much easier.

Figure 3.1. This is an API that was set up as many of the first platforms were created: the main product interacts directly with the back-end system, leaving the APIs as second-class citizens in the product hierarchy. Any new changes or features in the main product have to be duplicated in the API, resulting in feature inconsistency and incompatible resource representation.

Once you’ve established how you want your users to interact with your system, it’s best to support that everywhere. Imagine that a company has a product for creating and updating contact information for users; we’ll call it Addresser. Addresser’s main product is a website where users can view their contacts and information, and there’s also a mobile application to interact with the back end. The website makes a specific call to the back end and gets the result formatted exactly as it’s requested. The mobile application, on the other hand, makes a call to the API, which provides the information in a different format. Figure 3.2 demonstrates this case, where the main product communicates directly with the back-end system and is likely to retrieve data in a different way as a result. When the back-end system team adds a new “Location” field feature, and the Addresser website starts using it, it doesn’t show up in the API, nor in the mobile application, until an engineer has time to add it, doubling the amount of work necessary to keep the products consistent and increasing the likelihood of bugs in one product or the other one. This means that there will likely be a lag between the addition of this field to the main product and availability within the API. There’s a lot of technical debt incurred when you have multiple systems trying to reproduce a single interface; this setup means that duplicate work is needed in order to maintain feature consistency. In this case, the mobile app wouldn’t allow or see locations, resulting in developer dissatisfaction and customer confusion and irritation.

Figure 3.2. When an API is one of many different interfaces into the back end, the representation of a simple item (such as a user) can be different in many ways. Additionally, if the back end (in this case, the database) is changed to add more information, the interactions with each of the client systems will need to be changed, as will the clients of the API itself. This creates a large amount of technical debt because any change to the system has to be duplicated in several different places.

When you have multiple teams creating products without a shared vision, you also tend to have poor communication between those teams. The Addresser mobile team has no reason to interact with the main website team in order to help the back-end team create APIs that work for both products. This can lead to bug fixes in one code base but not in the other, or inconsistencies between the items available from the system, depending on which interface is being used.

3.1.2. API First model

What, then, would this system look like if it were designed API First? Figure 3.3 shows an API First model. The website and the mobile device get their information from the same API interface. This ensures that these resources will be consistent across the entire product line. Note that just because an API resource is available within the system, you don’t have to expose it to the entire world—you can decide which of the API resources is internal, partner only, or open to anyone. It’s still a great idea to have your API ready because when a major partner asks for access to some specific resources to support a use case, you have it ready to go. In the case of Addresser, the API may be designed to send users and contacts via the API to partners and client developers. At some point, there might be a location-based activity feed that a partner wants to create, but in order to create this feed they need to access the locations for the user’s contacts. In the API First model, this API is available because it’s being used by the website and the mobile application. You can make the decision to expose it to the partner wanting to create new and exciting functionality for your customers.

Figure 3.3. In an API First model, the back end only interacts with the API, which in turn drives the main product and all other implementations—the main product, mobile device, and other integrations. This reduces the need for duplicate code and allows each client to focus on exactly the pieces it needs.

API First also encourages communication between your back-end team and each of the client engineering teams. Understanding use cases at a high level helps you create APIs that are easy to implement for the use cases you understand up front, and more likely to support future use cases that come up. Once you’re creating the API as a larger team, you’ll find many places where different teams offer complementary resources, adding to a more well-structured system.

3.2. Code consistency

When you have two separate systems doing the same thing, you create a world with duplicate code. In the case of Addresser, the user object would be needed for the main product, but this resource would also be required for interactions with the API. If the queries to the back-end system might use different fields or connected data, the end products will not be consistent with each other—a common reason for user dissatisfaction with the company as a whole.

When your code base diverges in this way, you start creating technical debt for your company, regardless of who is in charge of writing the APIs. Two testing systems are needed, and when a bug is found in the main product it’s not necessarily fixed in the API—and vice versa. As you build more and more systems tied directly to the back end (for instance, you might have internal systems that access the databases for reporting), you create more dependency on that specific server implementation. If you share some code but not all of it between the different systems, changes to that implementation can break products unexpectedly. Additionally, when code is written in a highly coupled way (where dissimilar systems rely closely on other systems for convenience in coding), your system is highly interdependent and vulnerable to failure.

This issue has repercussions on the developer experience side as well. In a world where each project uses the back-end system individually, systems are likely to have different interfaces and represent resources differently, resulting in frustration for the developers and end users. Back-end systems are usually designed to meet specific needs, and unless the API is designed for a consistent developer experience across all interfaces, the developer may have to spend an inordinate amount of time trying to figure out what’s available and how the application can retrieve it from the platform.

Figure 3.4 shows system interactions when each client (including the API) accesses the back end through its own interface.

Figure 3.4. When different implementations are maintained for different clients, the user experience is different—and if, for instance, the reporting system adds new functionality to include the company for a specific user, the API would need to add it. In this system, the mobile and integration clients would need to add it as well.

As you can see, each of the clients grabs and uses a representation of a user, but each sends a slightly different request to the system. The API layer exposes the entire data structure, but the main product and the reporting systems grab only what they need. Because of this divergence, testing a change to the database requires working with each of the teams to ensure that nothing has broken, which requires the server team to track all the clients. In my years at major technical companies, this has been a serious issue; when one group owns a system and another group decides to leverage it directly, without an agreed-upon interface, client systems break when server systems change. For instance, if a developer discovers an undocumented method on the employee database to access employee data information in order to create an application for contact management, that application is vulnerable to changes because they didn’t work with the originating group to make sure their use case was understood.

An API won’t fix all the issues your production process may have, but it can make it easier to write code and architect changes with the right frame of mind. Once you’ve made the decision to attempt the API First approach, the focus moves from trying to maintain consistency across different product and code bases to designing, creating, and maintaining a strongly tested and well-designed shared interface. Decoupled code of this sort—code that doesn’t rely directly on the bare interface of the other system—protects both sides from unexpected changes.

How can you create this kind of model? The API needs to have a well-documented and well-understood interface, and calls to the back end should be completely protected from client access through any other means. This process does take more mindful consideration up front but has huge advantages, as you’ll learn in the following sections.

3.3. Functional equality

In the API First description, I mentioned a contacts application called Addresser. A common problem created by a model of this sort is where the main product gets a new feature in January but the API has to wait, sometimes for months, for the engineering resources needed to provide the same functionality. This issue can be avoided, but it’s rarely the case that a company wants to delay the release of its main product for something that’s considered “extra.” Until the engineering organization determines that the API is a first-class product, this delay will exist, and in many cases the team who understands the new functionality is moved along to new projects before the API is created, resulting in an API created months later, if at all, by an engineer who isn’t as familiar with the goals of the functionality change as the original team. The result is a poorly designed API.

If the API is integral to the main product, though, it’s updated, tested, and deployed as part of the main change. It’s ready to use and tested by the main product, and when you want to expose it to your other applications and developers, whether internal or external, it’s ready to go. Having features available to release allows you to enable partner integrations quickly—trust me, your premium partners will want the functionality as soon as they see it—and open it up to your internal and external developer partners for use as you see fit.

Even if the API is ultimately used only by the engineering team for the main product, this approach still encourages consistency in the product’s representation of resources and will help your product developers create integrations and applications easily. API First also allows the back-end engineering team to change the back-end database or server system without impacting the developers; the interface is documented and understood. Because the clients are going through this layer of abstraction, the engineering team knows exactly what they need to support with any changes to the back-end system. You’ve already documented the interface, so when your company decides to add new products, the available resources are ready and well documented. New clients wanting to use the API can work from the schema model to make sure that the use cases they want to implement are easy and efficient.

3.4. Increased productivity

It’s somewhat counterintuitive that adding an extra layer to your system could reduce the amount of overall work that your engineers have to do—but remember that once you have the design for the interface defined and engineering teams start using it, they can share client libraries and other tools for interacting with your stable API interface. Although it’s possible to write modular and decoupled code without this extra layer, it’s much more difficult to do so well. Without a guiding vision, each development organization will determine exactly what they need to meet their goals, and so the clients will diverge rather than converge. API First means that you need resources assigned to make sure that your APIs will work to support your main product(s) easily and that your interfaces will be consistent. The goal is not to hamstring your developer partners by reducing their access to the data, but to make sure that they’re getting what they need from a single source.

Once your developers are using the API to feed their products—whether internal reporting systems or third-party applications—they’ll no longer need to write the duplicate code to access your back-end system. Each client will have access to new resources as they become available, and you can expose them to different classes of developers (internal, partner, external) as needed.

Running all your applications through the API may also reduce the need for multiple representations of the same object (for instance, First Name, Last Name, and Full Name). But having two different representations available is also of value; if the users of a client application prefer one representation over another, it’s simple for the client to switch to using that representation.

The quality of your system will also be improved. When you have a single interface through which all of your data flows, you can test it more easily and consistently. Changes to the platform can be run through unit tests (as all code should be) as well as integration tests based on the use cases that you support. In fact, you can use the use cases for your system—including the main product, reporting systems, and integrations—as the guiding models for the API you create, and those use cases can also drive the testing you do against the system.

Although your back-end engineers may not appreciate the extra work up front, they’ll start to realize that it’s saving them time and effort. Your developer partners will thank you for the feature consistency they enjoy—where they are given access to everything that makes sense, rather than the features you’ve had a chance to implement in the API. If you make a decision to hold back features for only internal development, you can communicate it to your external development community so they understand that there’s a business case preventing the access—and if they can provide you with a use case you want to support, you can revisit the decision. If the data is not available through the API, making that decision comes with much more overhead, and the inconsistency will stifle the enthusiasm and creativity of your developer users.

3.5. Internal/external access

On the flip side of open and transparent access to data is the gripping terror that enterprise companies experience when they consider opening all their data to the entire universe. The open API ecosystem started out this way, with open APIs making it possible for third-party developers to access the system and make changes or view people’s information. This was a visible aspect of web APIs, and it caused some inaccurate assumptions about restricting access based on the application and/or user accessing the system. Large or heavily security-conscious companies were concerned that having an open API would expose their proprietary data without any control or restriction. The easiest way to dispel those assumptions is to understand how API management can allow companies to control access to specific functions. Figure 3.5 illustrates an OAuth request, one of the options for API authentication and authorization.

Figure 3.5. In an OAuth request, the client and server both know the application and user keys, but they also have “shared secrets” at the application and user levels. The request is built using the nonsecret data, and the encryption is done using the shared secrets. The client creates the request and signs it with the shared secret, sending it to the server. The server takes the request and also signs the request, and then compares the signature it created with the one sent by the client. If they match, then the client passes the authentication check and the request is allowed to proceed.

The authentication and authorization systems such as OAuth that have been developed for APIs make it relatively easy to define which pieces of an API are open to internal developers, as opposed to partner or external developers. Along with authentication and authorization, these mechanisms make it possible to know which developers, and which users, are accessing the API in which ways—a huge help when trying to debug problems.

Authentication and authorization mechanisms give you total control over which people can access your system. Depending on how your data is structured and the types of information you want to keep back from the public APIs, you can decide to expose different fields for each type of data. In fact, this is one way in which an API abstraction layer makes it easier to provide system access to your partners without having to allow them direct access to your company’s critical data systems. Adding an authentication system on a well-designed internal API to expose certain elements to customers and partners is much less work than creating a new interface from scratch for them.

That’s not to say that it’s a bad idea to expose information to the open developer ecosystem. Third-party developers can help by previewing new API resources, giving you feedback on what works, and validating those use cases for you to make sure they work as you expect. This is a type of “free” testing for your APIs, and if there’s not a business case for holding back API functionality, you should definitely expose it. If writing to the system is something that the company is concerned about, allowing open developers read access to the resources can help you by exposing issues with your API that you hadn’t previously considered. Take advantage of this potential; when you treat your developers as partners, they’re usually willing to work with a beta or release-candidate version of your system in order to get a leg up on their competitors.

One other consideration when planning for your API is that even if your API is internal only, you want to create it with the same care as you would for an API that you might eventually expose to the world. There are a few reasons for this. First, you might eventually want to open up that API, and if it hasn’t been crafted for a fantastic developer experience, you’ll either have to suffer the consequences of a poorly designed API or start again to create a new API that duplicates the effort of the previous one. Second, and more important, it’s a terrible idea to assume that because your customers are internal you don’t have to create a great experience for them. When developers are forced to use an unusable system, it creates a huge support burden—when these developers can’t walk away, they’ll keep at you about the things that are causing them trouble. When designing your API, think about who will be using it (internal, external, partners). Authentication and authorization are less important when you’re behind the firewall, but it’s still much easier to triage issues when you can track down exactly who is doing what with the platform.

API First will provide your platform organization with the same advantages no matter who the customers of that API will be. Consistent and decoupled code will reduce bugs and regressions. Feature equality will make it easier to allow potential customers to integrate with your system—without scrambling to catch up after the need is clear. API First improves the quality and velocity of the code that’s written, allowing your developers to focus on new functionality while spending less time chasing down issues.

3.6. Case studies

Although API First can seem like an excellent idea in theory, I’ve consistently heard engineers, managers, and executives say that they couldn’t possibly implement this type of system for their company. It’s true that adding an additional layer to your infrastructure creates more work up front, but the advantages can far outweigh the downside. For further context, this section talks about some case studies to demonstrate how companies have moved to this model, or started with it, and the results they’ve enjoyed as a result.

3.6.1. API as the main product

Twilio is a successful company that provides telephony services via API (see figure 3.6). For instance, if you want to add SMS or other phone capabilities to your application, you’d need to integrate Twilio using its APIs, and your development time would be reduced substantially. Telephony is something that’s hard, and Twilio is a great example of a company that’s making significant money by simplifying hard (but important) functionality.

Figure 3.6. Twilio’s system, with APIs for both internal and external functionality. Although Twilio uses its billing and configuration APIs only internally, the discipline it exercises in making sure that everything it does uses the same API system helps to ensure that the system is consistent and robust.

Twilio’s only real product is the API, and they charge for usage based on how much a developer uses. When the company started out, the APIs it had were restricted to the basic product, but as developer partners increasingly started using the platform in a more complex way, Twilio realized that it would do well to create APIs for the configuration, billing, and other website functionality that supported its main product. It still has some back-end systems that don’t expose APIs, but anything that’s available for developers to do with the system is available via API as well.

An important note here that we’ll revisit in chapter 9: Twilio is widely considered the industry leader when it comes to developer support; it has a team of evangelists who attend hundreds of hackathons each year to help developers become familiar with its platform. Twilio has a strong commitment to developer support, even encouraging its evangelists to help developers work on code that isn’t related directly to Twilio. It has a goal of providing documentation and resources so that new developers can make their first successful API call within five minutes. One of the major advantages to having a team of evangelists of this sort is that they’re constantly getting feedback directly from developers that they can funnel back to the development team.

3.6.2. Mobile First

Instagram, a photo application, was initially created as a mobile application. The most efficient back end for the company to use was a web API, and Instagram created one for use only by its mobile applications. After several months, users started to request a website and integrations with other systems, but the Instagram team didn’t have the resources or time to implement these things. Frustrated by the lack of access, some third-party developers reverse-engineered the system to create an API, which encouraged Instagram to open up its own API system to developers. But since it had started out API First, adding API management and authentication around the platform was relatively quick and easy, and the developers then had what they needed in order to create the products they were looking for.

3.6.3. Refactoring for API First

Etsy is a major online crafting marketplace, with over $1 billion in gross merchandise sales revenue in 2013 alone. In 2014 it decided to change to an API First model in one go. The previous API was a big success, allowing third-party developers to integrate with the system and meeting the needs of buyers and sellers. Unfortunately, the system was a mirror of the back-end database, not crafted toward specific use cases, and not efficient to use or maintain. Mobile application developers were frustrated that they had to make multiple calls to render a single screen—an antipattern that makes mobile applications fragile and nonperformant (users tend to walk into elevators or drive into tunnels, and it’s important that the application can get the information it needs efficiently).

Etsy refactored its back end and APIs to support the new scheme and created strongly RESTful APIs on which it rebuilt its main products. To support its mobile clients and other clients who needed a slightly different setup, the company created a batching system called BeSpoke, where it could identify resources as bundles of other resources. Moving this complexity to the server meant that Etsy could better support all of its developers and keep track of how the resources were being used, and it could run concurrent requests for these bundled responses, which improved the efficiency even more. The business logic was maintained in the system at the API level, so authentication and visibility were consistent no matter where a user was interfacing with the system.

This ambitious undertaking had the outcomes Etsy was hoping for: increased velocity and consistency across resources and products. Its previous system had grown organically over time as the company grew, so taking this opportunity to refactor the system gave Etsy the ability to improve the responsiveness, scalability, and consistency of its system. There were unexpected benefits to this change as well. Etsy noticed that the communication between its development groups improved noticeably; the mobile team and website team were engaged with each other in defining customer experience and what was needed from the API. Etsy even had an unexpected bonus in that the activity artist feed—one of the products it hadn’t targeted with the change—was able to go from an asynchronous call of several seconds to a subsecond call. This change meant that Etsy was able to move from regularly refreshing the resource offline to returning the information on demand when users requested it, reducing the resource need and providing a better, more accurate user experience.

As a second example, 3scale is an API management company, providing a platform with tools for companies to manage and administer its APIs (see figure 3.7). It should be no surprise to learn that all internal and external processes—indeed, all of the systems used by the company—run on web APIs. Anything customers can do with the product can be done through the API, because those products are running directly from the same platform.

Figure 3.7. 3scale’s evolution from standard implementation to API First moved it from a system where most of the customer visible functions were available via the platform to a system where each function within their system worked via the same API platform. Again, this made 3scale’s system more robust and made it easier to expose new functionality to users as requirements dictated.

When 3scale started, the company was looking to solve the problem of managing the traffic flow on APIs to ensure it was safe, scalable, and accessible. Steve Willmott, the CEO and cofounder of 3scale, has often said that his goal is for everyone to be able to have an API.

To start, the solution was to separate traffic delivery from management: deploy the management dashboards, analytics, and policy management in the cloud and provide code plug-ins in many languages (Java, Ruby, and Python, and more). Each of these clients hit a set of APIs on 3scale’s cloud platform. Using the plug-ins, customers could deploy the functionality in their own applications. These plug-ins evolved quickly, and the API mediated all the calls, capturing stats and becoming the backbone of the service. Later 3scale added extensions for web proxies like Varnish and Nginx so these could become fully fledged, high-performance traffic gateways, all communicating with the APIs.

The first versions of 3scale’s dashboards didn’t come with APIs. Given that it was capturing analytics data and had customers consistently asking for complex configurations, it became clear that the only way to meet these needs was to add APIs across all functionalities. In one of the major version changes in 2010, 3scale developed comprehensive APIs for every part of the platform alongside all of the user interfaces, switching those interfaces to run on top of the APIs—truly API First. Since then, the API and product have always been updated in parallel.

3scale is in a competitive market, and running its business on APIs in this way has allowed the company to enable many more customer use cases than would have otherwise been possible. Today, many customers use 3scale as a platform underneath other systems that add further functionality. The traffic management API architecture also means that today 3scale can apply management to APIs delivered across all sorts of systems—from content delivery networks to a customer’s own homegrown web server layer.

3.6.4. API First strategic direction

Akamai is a company providing content delivery services for companies looking to add reliability and scalability to their web properties. Akamai’s business model for APIs is slightly different than the other companies discussed here: rather than deal directly with the customers who are consuming the content, Akamai works with administrators who configure, maintain, and update their properties (websites) using Akamai’s tools. The nature of this system is such that a great deal of the internet runs on Akamai servers, so any change to the access or configuration controls needs to be controlled carefully.

Historically, Akamai had many APIs for customers to use for reporting and configuration, but these APIs were inconsistent in authentication and interaction. Customers who wanted to integrate with these systems were required to learn a new model every time they integrated with a new API, and support, maintenance, and improvement were inconsistent and frustrating.

In 2012, the company made a decision to move all of the configuration and product behavior to an API First model using a single API system called EdgeGrid. Because of the need to protect stability and security, Akamai couldn’t make a sudden refactor happen without potentially compromising its critical systems. Thirty percent of internet traffic comes off an Akamai server, so any errors or issues could cause serious repercussions for both the internet and the company itself.

Akamai was committed to making the change to API First in the best and most efficient way possible, so the decision was made to move to API First as a strategic direction: put the self-service portal and other products in front of the API and make those APIs available, where appropriate, to partners and customers. As new products were created or existing products updated, web APIs were created. An API architecture team assisted the product teams in creating APIs that were consistent with those of the other teams.

Akamai had an aggressive goal for bringing its system in line with this model: while keeping in mind the sensitivity of the existing system, the company aims to get most of the work done within the course of a couple of years. Given that most of the systems have been in place for many years, reimagining the components and rebuilding them based on the current and predicted usage takes time. An important thing to realize in this case is that when you’re asking multiple business units or teams to come together and work as a larger team, you need guidance, vision, and support from both the high-level executives (the refactor won’t generate new revenue on its own) and from an architecture team who can review the new APIs as they’re created to make sure they’re in line with the goals of the overall platform strategy.

3.7. Summary

In this chapter, you learned about the concept of API First, the advantages it can bring to your company, and how to choose the right level of privacy. We explored case studies of companies who have made the decision to implement their system in this way.

This chapter covered the following topics:

• The API First design methodology moves the web APIs in front of the back-end servers so that all products, APIs, and integrations are running off the same system.
• Without API First, API code that duplicates the main product code must be written and maintained, leading to reduced performance and inconsistent behavior in the system.
• When an API is a side addition to the product, new features given to the main product will lag behind on the API side until required. They should be created at the same time, with the same goals and vision—or, ideally, they should be the same thing.
• Removing the duplicate code and having strong communication between the teams, as well as strongly defined interaction points between systems, make it much easier for your platform developers to release new features or changes.
• Just because an API has some open aspects doesn’t mean that you have to open everything up to the world. Creating a solid and consistent platform that meets your internal needs is a valid goal on its own—and if you do want to expose the information externally, you can do so with some additional security mechanisms to protect sensitive data.
• Etsy is the best example for companies who have gone API First from a more monolithic model. Moving to API First improved its velocity, increased cross-team communication, and improved sections of its product that it hadn’t even targeted.

The next chapter gives you a solid introduction to web APIs—from the HTTP framework behind them to descriptions of how REST APIs work with that framework to create functionality.