Analyzing information needs and structure

Overview

Diagrams with boxes or sequence diagrams - not everyone’s cup of tea and not the best to capture data and functional needs. Defining API design from code is the most expensive option to change. The alternative way to design APIs is to use the Data requirements and API design canvases.

‍Almost every API should be designed as if it could be used by external API consumers. The most important things to design are data, data formats, documentation and security.

‍

Top 5 concepts

Start with the top 5 concepts, then continue to validate them with the questions.

The top 5 concepts are logical concepts, usually nouns, that make up the core of the API under design. For example, products, customers, ingredients, and locations are core concepts for a food delivery API.

Sometimes you will notice at this stage, what you thought would be one API or one endpoint, is actually splitting into several.

After you have the initial core concepts, start working your way clockwise in the template.

What questions the API consumers need answers to?

Write down questions like "What products can be delivered to my location in under 30 minutes?". These will form the bases of your GET-requests, in this case for "products" -resource aka. endpoint. Your variables will be location (possible address or geolocation) and delivery time (in minutes). Your response will contain a list of products, that you have to identify somehow.

International, national, industry specific or company wide data standards?

You already identified products, location and time as concepts. What regulations or standards are related to these, for example ISO-standards or legal requirements? Good starting point are the schemata in schema.org where most concepts have been described as a ready made schema with examples and proper standards.

Products is a notoriously tricky concept for standards, because each industry has it's own set of standards for products, even though there are some globally standard identifiers.

Common identifiers and required attributes?

The products and locations need to be identified, for sure. But how? Location for example can be stored as co-ordinates or with address schema containing street address and ISO code for country.

Which attributes do you have to really have to ask the question? Do you always have to give location? Probably. But what about the delivery time? Is some default time used, if it isn't given?

What about the response? What is the minimum information needed about products in this case. Is it enough to return identifier, or should you also include product name in the response to make it easier to the client consuming the API. This is ok for GET requests, but do we also offer an API endpoint for creating products or orders? What are the minimum requirements then?

‍

How fresh the data needs to be?

How fresh is fresh data is always a relative question. In this example case all we know is that the food delivered as a result of the API must be fresh. The list of products might be quite stable, but the availability and queue size of orders waiting to be delivered might vary. Is 5 minutes enough or should it be 30 seconds or 5 seconds? All of these options have different requirement on integrations, humans updating the information or processing the queue and the customer experience.

‍

Considerations for data requirements

Private APIs are used by one application, internal APIs by several internal applications. They contain attributes and data that are business-critical and confidential.

Partner APIs are available for third-party organizations under partnership terms and conditions. Partner APIs may contain partner-specific or customer data which is not available in public. 

Public APIs allowing self-registration can require authentication. Usually public APIs contain data that has access to the underlying technology or data can use to access their own or any available data. Some public APIs may offer data licensed as open data, but an open API does not always offer open data.

How to use the Request & Response -template

Request & Response is the typical pattern for any APIs, including REST APIs. It may not always be the most efficient, though.

A lot of polling is needed to keep the data fresh, because the API consumer won't know if the data has changed in the API provider side.

Start from the left-top corner by designing the request and then design the right-bottom corner, the response.

What needs to be done in the middle to perform the request and clean the response, depends on the systems and data sources involved.

‍

The Request

Use bullet points and example data to describe the attributes needed for the request. Dissect the questions from the Data requirements -template as requests (one question should be one request).

Also creating or updating data requires a request, but move to this after processing the questions (the GET -requests) first.

‍

The Response

Use bullet points and example data to describe the attributes needed for the response. Describe what the response will contain. Remember the response is the "answer" to your "question" set in the request.

In case the request contains data to be created or sent for processing or updates, the response is possibly empty or contains only an identifier.

‍

Perform request

The systems, data sources and algorithms, possibly even other APIs that need to be used to handle the request.

Because we are still on the business language and logical level, write the processing rules in a human language sentence: "Check which cooks have an order queue that will empty in given amount of minutes (deadline) and what products (pizza, pasta, chinese) are they able to make?"

‍

Response values

This step is about cleaning the values and combining different data sources so that the performed results can be sent as response. This step can be optional, depending on need. Use it in situations where it's clear that some identifiers, categories or for example time stamps coming from the underlying systems or logic need some standardizing or cleaning up. Use this step also to describe filtering out data and operations due to access rights of the user.

How to use the Events -template

The events (or push or hooks) -template is used for a subscription based model where the API provider will inform the API consumer when some condition is met and data or state is changed.

‍

Request subscription (at the top) is done once, when the API consumer subscribes to hear about specific events.

Process event layer (middle) is for describing triggers and processing rules for specific event, for example when product delivery is confirmed.

Subscription removal (bottom) is used for describing how the subscription is removed when the API consumer no longer is interested in the events.

‍