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.
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.
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.
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 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.
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.
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.
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.
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?"
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.
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.