8 API Questions To Ask When Developing a Public API

Application programming interfaces (APIs) are a cornerstone of gathering and developing the data that has become vital to business. Data tracks organizational performance, helps businesses find and develop leads and prospects, and can even improve conversion rates.

APIs have gone from a niche function to a focal point of business strategies in everything from marketing and partnerships to customer service. 

While public APIs are business-driven tools, keep in mind that they are still pieces of software and need to be approached with careful attention to detail and planning—like any other software development project. 

Before building your API, you should consider some important aspects of the API development process. This will ensure that the tool you end up building is the one that can help your business thrive. Our discussion will help get you started.

• What is API design?
• What factors should I consider when hiring an API developer?

What is API design?

API design is the planning that goes into how the two systems involved in the API—clients and servers—will interact. Depending on how your API is set up, those interactions might be server-to-server or client-to-server, and the API design will impact how those experiences occur. 

It also considers how people will access and use the API. So, you’ll want to design your API based on what will be most helpful for your customers rather than just how your internal systems are set up. Because of the disparate people who will use it, the API design process often involves collaboration between different teams, such as the customer service and sales teams.

Consider what data should be available for customers to access and how you want them to access it. You may want to organize your data in hierarchies or use a classification system that allows you to group the pieces of data based on what’s needed to complete specific actions.  

To design your API, you’ll want to work closely with the developers helping you create your tool. They’ll be able to understand how you’d ideally like customers to interact with your API and determine how you can reasonably build something that meets those expectations.

Well-designed APIs can boost a business’s internal operations and enhance marketing and sales strategies. For example, Zillow has a public API that allows you to use custom real estate data, such as a Zestimate, and publish the data on your site.

There’s more than one kind of API, each designed for a different domain. These include:

• Open APIs. These are also known as public APIs. These systems allow developers and users to easily access the information they contain. These tools allow users from outside the system to access the information or services provided through the system.
• Internal APIs. An internal API isn’t available to external users. These tools help people within an organization exchange information. For example, different departments might need access to each other’s data to accomplish business goals.
• Partner APIs. A partner API has a similar structure to a public API; it allows people from outside the organization to access information provided by the servers. However, these systems have restrictions regarding who can access them. For example, people who have paid a membership fee.

Within these different categories of APIs, you might also encounter web services and web APIs. These types of APIs can be public or private. 

Web services consist of an API that uses a network connection. A network is a system that connects two or more pieces of software. Most commonly, this connection is the internet. 

APIs can use a network connection, but they don’t have to. Two applications may run on a single computer and communicate with each other through an API but not require a network connection.

Meanwhile, a web API is an API built specifically for the web. They can be used with both web browsers and web servers. 

As we explore questions that can guide the creation of your API, we’ll focus on open, or public, APIs.

What factors should I consider when hiring an API developer?

Before hiring an API developer, think carefully about the type of API you want to create and how you want to design it. Careful planning will enhance your ability to create a system that genuinely benefits your organization. Here are eight questions to ask during API development.

What is the business value of your API?

Ask yourself why you are building an API. Quantifying why you are building the API and the value it holds for your company will help you move forward. 

To answer this question, look at sources like user stories and use cases. Consider how an API for your specific business model can help you generate a new revenue stream, streamline processes, or strengthen partnerships or customer relations.

API goals can include:

• Increasing your ability to work your way into the mobile market
• Improving internal communications
• Creating opportunities for the monetization of certain services
• Enhancing customer satisfaction or loyalty
• Increasing productivity and efficiency
• Decreasing costs
• Expanding sales and engaging prospects

As you consider the value that the API can have for your business, also consider how long it will take to build the API, how much the API development process will cost, and whether you already have the database ready that your API will access. You might look at factors like user stories or use cases to better understand how the API will factor into your business planning.

To better understand the cost and value of your API, develop a business case. A quality business case can help you iron out the details surrounding your API. Your business case should be able to answer the following questions:

• What problem or compelling need for change will the API solve?
• What’s the return on investment you hope to get based on the business need you’ve identified?
• How does the cost associated with building and maintaining your API fit into your business budget?
• How will you manage the building and maintenance of the API?

Begin by considering your goals for the tool. If you want to help customers access information from your site, consider the value this will offer your business. Do you want to see an increase in purchases? Estimate with your team what you plan to achieve and develop KPIs that let you see your actual results. 

Then, look at the costs you will incur. Consider how much it will initially cost to build the API and what it will take to run it month to month, so you can plan for your budget moving forward. 

Who is your API audience, and what do they want from your API?

Designing your API calls for a close analysis of what you hope your audience will achieve. A firm understanding of what people will do with your API can help you improve your organization and structure.

Answer questions like:

• What types of projects or tasks will your audience use the API to accomplish?
• What technology requirements will your target audience have? For example, will your target audience demand a particular language?
• What types of devices will your audience use the API on? This might include mobile devices, desktop, or wearable devices.
• Will this API fit particularly well with certain industries or business sectors? 

For example, if your audience includes business professionals who might use your API in the creation of their own websites, you might have a different design than if you were targeting Gen Z shoppers who want more information about your inventory. 

You’ll also have different considerations if your API will work with a secure industry, such as banking. For instance, you might create a login system for users to authenticate their identity.

Your ability to capture what your customers want to see as they access your API will directly impact the user experience that people have with your system. When your API is organized and optimized based on their preferences, it’ll be easier to market the API to your target audience and attract users.

What are your API’s affordances?

Affordances are the permissions you allow and the tasks you design the API to do. When you think about the security and structure of your API, consider what you want people to do with your API when it’s first released and also how you hope the system will grow with your customers (and your business). 

For example, if you need to scale to add more access or if you want to include more services through the API, your system’s present and future conditions will play an important role in how the API is set up and the security you need.

As you build the security around your system, you will determine which assets are exposed and how. Carefully consider what data can be accessed through the API and use principles of least privilege. Ensure people accessing your site API can only pull the information they absolutely need. 

You’ll want to manage the databases that the API call accesses so people can’t reach unauthorized information. Limiting the number of times a particular person can make a request within a given period can also help you limit certain cyberattacks, particularly Denial of Service attacks. The API should also work hand-in-hand with a firewall that can understand the API requests while also protecting the rest of your server.

Your business model will also play an important role. Consider if you have any relevant compliance or regulatory requirements to keep in mind. These types of requirements will impact how you set up your API and how you create permissions within your system. 

What is your software schema and data format?

Consider the different data formats—such as JSON, which is a subset of Javascript, or XML—as you begin your API design. Each system has its own benefits and drawbacks. JSON is popular for its compact nature and ability to work well with JavaScript-based web apps. On the other hand, XML is also popular due to its power (though it generally requires more work from programmers).

The data format you use will need to be understood by the server receiving the request for the API. If the tool also needs to integrate with systems like your Customer Relationship Management (CRM) platform or Enterprise Resource Planning (ERP) platform, for example, know what data systems can be used to communicate. 

Work with your developer to make sure you know what data format your server can accept so that communication remains smooth between the two parts of the system.

Your API will also need a schema to help facilitate communication between the two servers. A schema helps define all of the tables and fields contained within a database. It defines the operations that can be run by the API. SOAP APIs traditionally used Web Service Definition Language (WSDL), while REST APIs use OpenAPI.

Do you need to set use limits on your API?

Use limits are a necessity for companies running APIs. If you don’t have any defense in place against overuse and abuse, you may not have the bandwidth to adequately protect your server and keep your costs manageable. The type of limit you need will vary depending on the type of API. Some types of protection might include setting rate limits or throttling. You can also implement data transmission limits and call volume by application limits. Your limit will likely depend on how much use you expect your API to have. 

However, you also want the capacity to scale your API as your business grows. If the limits of your business need to be bumped up at a later date, know your plan for dealing with that particular situation so your API doesn’t limit your growth.

Consider the data transmission limits you want to see and discuss them with your customer service and DevOps team. They can help you better determine what limits would allow your business to optimize its engagement with leads and customers without overburdening the system. Setting the limits too low could end up hurting your customers, so make an informed decision. You also want to consider the necessary scalability so you are fully prepared.

Will you use REST or SOAP? 

You also want to consider if you will use a REST- or SOAP-based API. These are two of the most common styles of “writing” APIs; knowing which one to use and how the benefits and limitations align with your needs will be critical.

These two types of APIs will impact the structure of your tool. Each comes with its own benefits and implications regarding how the API can communicate with the server.

The Representational State Transfer (REST) API paradigm is based on the HTTP protocol. These HTTP-request APIs can be simple to build and scale according to your business needs. This system will use status codes to send information about the client’s request. These can also use caching to store copies of data that users frequently want. They use Uniform Resource Identifiers (URIs) to convey resources. 

On the REST API, decide if you want statelessness (meaning each HTTP request happens in isolation from other requests) or if you want requests to also keep in mind information requested in the past.

SOAP (Simple Object Access Protocol) creates a more complex API. It relies exclusively on XML, offers considerable opportunities for expansion, and comes with a variety of options for standards. The idea is that developers then use the standards required for a particular program. Note that while SOAP does not leave much room for error, it does offer information in its error messages that guide you in fixing the problem.

Interestingly, SOAP doesn’t have to be connected with HTML. It can also be used with the Simple Mail Transfer Protocol and other transports. However, these API are designed to be neutral and operate with nearly any programming style.

You can learn more about SOAP and REST to help you make a better decision.

Are you planning to monetize your API?

You also want to consider if you plan to monetize your API. You can set up structures that allow you to generate income through your tool, such as setting up permissions that allow people to pay for additional access and features through your system. For example, people might decide to pay a monthly fee for access to more calls through your API.

Consider if you want to offer this type of payment for your API and how it will impact your setup. It will also likely impact your API business logic, or how the data is manipulated between when it is out of storage and when it is presented to the user.

How will you measure API success?

Finally, you need to decide how to gauge the success of your API. In the beginning, you determined what your goals were for your API. You can use this information to consider which factors to measure. 

Tracking your tool’s ROI will not be an exact science, so you need to predetermine which KPI you want to measure for your system. You will need to know how you will conduct end-to-end API testing to verify that your tool functions.

To test your API, work with your developers to ensure that it works as intended. This will involve sending some requests through the tool to make sure it retrieves the correct information. Performing load tests can help you determine whether the API can handle multiple requests at once. Work with your developer to find tools that will allow you to automate your testing.

Looking at key factors like the conditions under which the API fails (and what happens when it does) can ensure that your API remains helpful to your customers and provides consistent error messages when something goes wrong.

Use this information to help you see how customers use your system and where you need to optimize your creation. If you see people creating a use case you didn’t previously consider, you might need to keep this in mind in a future upgrade.

On the other hand, if you find that your API can no longer support your system goals, even with upgrades, it may be time to retire your API and design a new one. 

If you find the time has come to delete your current version, tell your customers beforehand so their systems aren’t damaged in the transition. Consider a weather company that builds an API allowing the public to offer weather information on their own sites by pulling it from the weather company’s site. If the weather company doesn’t warn their customers, it could disrupt their customer’s sites when the API is deleted. You want to give them time to fix any problems that might arise because of your API deprecation. 

If you will be upgrading your system, see if you can provide an upgrade path to those who use your API to maintain a positive user experience. Recognizing the end of what an API can do for you is just another part of the API lifecycle. Helping your users adapt is an important aspect of this process.

Build your business with API

Working with a service provider can help you create a powerful API tool for your business. If you don’t have the capabilities to do this personally, you can find independent contractors on Upwork. 

Through Upwork, you can find professionals with extensive experience using different languages and systems, including Java, SOAP, and HTTP. You can browse portfolios of past work and find professionals with the credentials you need. All you have to do is create a profile on Upwork. You can then post your job and review the bids that arrive. Find an API developer who fits your needs and get started!

And if you are a professional with extensive experience building APIs, you can nurture your career through Upwork. Create a profile to highlight your skills and browse jobs that fit your skill set. You can then bid on jobs and earn money helping customers create these important tools. It has never been easier to build a career as an API developer than with Upwork.

Upwork is not affiliated with and does not sponsor or endorse any of the tools or services discussed in this article. These tools and services are provided only as potential options, and each reader and company should take the time needed to adequately analyze and determine the tools or services that would best fit their specific needs and situation.