Technical Skills for Product Managers: API

How to use the checklist

➡️ Understand API purpose: to delegate the work to another service (the diagram on the left)
➡️ Understand API structure: API address, API Description, Input/Output parameters, Possible Errors (the diagram on the right)
➡️ Explore the example of a real API call:
https://api.memegen.link/images/ski/Product_manager/Just_called_an_API.jpeg
➡️ Use the table below to find your situation and what to do in that case
🚀 Want to boost Tech skills? Level up with the "Tech Foundations for Product Managers" hands-on course

We need a new functionality that is already available via API inside or outside the company We need to add the feature to switch the currency and convert the price into it;1) Search for documentation (internally or online). 2) Read the description of the API endpoint that best suits the requirements. 3) Understand the input parameters (what we will need to somehow get from somewhere in our product and send to the API). 4) Understand the output parameters (what we will receive from the API and use in the product). 5) Understand possible errors (we need to know these to be ready for the fact that the response will not always be successful). 6) Understand whether the API has any special features (for example, whether the API is asynchronous). 7) Great, now you can write a task for the integration team: what/why to connect, what parameters to send and which ones to accept. ;1) Found https://openexchangerates.org 2) Found the /convert endpoint 3) Saw that we need to pass the current price, current currency, and target currency. 4) We will get the converted price value back. 5) If we pass an incorrect currency code, the API will return an error. 6) No special features, it is a very simple API. 7) Simplified version: “We need to exchange currencies between RUB, EUR, USD. Here is the API - access has already been paid for. We need to pass the current basket price and the currency selected by the user there and return the resulting converted value to the UI for display. In case of an error, return “Conversion failed, try again later.”;Three practical examples of working with documents in the simulator "Tech for PMs" link=https://productdo.io/tech_pm; I want to understand what the main APIs of our product are I joined a new team and I am trying to figure things out;1) Ask the Engineering Manager or tech lead to describe all the APIs that we expose to clients. 2) Ask them to describe what these clients do with our API responses.;1) We have a review service, so our main APIs are: /submit_review(ride_id, rating, text_review) → “OK” or “Error” /get_all_reviews(driver, period) → List of {date, ride, text, rating} 2) We are called by the main application to submit a review, and also by the driver page to get a list of all reviews.;Two cases for creating your own API in the simulator "Tech for PMs" link=https://productdo.io/tech_pm; I want to understand what other services/APIs we depend on I joined a new team and I am trying to figure things out.;1) Ask the Engineering Manager / Tech Lead to describe all the APIs we depend on. 2) Ask: are these dependencies stable, were there any SLO violations?;1) We depend on the notification API, which we use to remind the user to leave a review. 2) Last month, the API broke three times and “broke through” the SLO of 99.9% (actual: 93.1%) - so we need to go and argue with the PM of this API.;Three practical examples for assessing API dependencies and SLI/SLO in the "Tech for PMs" simulator link=https://productdo.io/tech_pm; The client requires creating new functionality via API They ask to return the approximate delivery time of the ordered food;1) Meet with the client, understand the requirements: what and why they want, what are the use cases, what data they have and what they want to get back. 2) Offer API “contract”: input parameters, output parameters, possible errors. 3) If we agree, then roll out this API in test mode (programmers know what it is). 4) Write clear documentation: description of the API, each parameter and all errors. 5) Add API monitoring (Service Level Indicators) and agree on Service Level Objectives (SLO). 6) Roll out the API to full production.;1) The UI team wants to show the approximate delivery time to the client who ordered food. 2) Suggest that they pass us the restaurant and the customer's address, and we calculate and return the time estimate (for example, the average cooking time in this restaurant + delivery time). 3) We agreed, rolled out the API in the "sandbox" in the next sprint. 4) I prepared clear docs. 5) We defined SLI: reliability and latency, and set SLO for them: 99.9%. 6) We rolled it out, the API is available at /foodorder/v1/delivery_time.;Two cases for creating your own API in the simulator "Tech for PMs" link=https://productdo.io/tech_pm; I want to try the API myself The team says “API is ready” - I want to check it myself, can I play with it?;1) If it is a GET endpoint, you can simply do it through a browser (see the example on the right). 2) If it is a GET or POST endpoint, you can call it through Postman;1) Here is the Meme API: https://apimeme.com/meme?meme=Spiderman-Computer-Desktop_Even_Spiderman_studies_at_ProductDo (see also the diagram above). 2) The Postman example is a bit more complicated to set up, see the course "Tech for PMs".;Three cases for calling the Taxi API in the "Tech for PMs" simulator link=https://productdo.io/tech_pm; I came across a difficult API integration Several services call each other one after another;1) Create Sequence Diagram, an you will see all the dependencies clearly. 2) Display all the features on the diagram. For example, what to do if the response is returned asynchronously? And what to do if this call returns and error, do we stop the entire call chain or try again?;1) For the Sequence Diagram assignment, see the course “Tech for PMs</a>”;Sequence DIagram use case in the simulator "Tech for PMs" link=https://productdo.io/tech_pm;

Legal

support@productdo.io