In day-to-day communication between the mobile team and the back-end team, you can see it is the common words that they talk about together. In this post, I’ll like to give you some more deep points about the API that a PM may need to know.
Basically, API means application programming interface, a.k.a the way to “communicate” between two systems. In this situation, it is the way — the interface —that the mobile team can get or submit data from/to the back-end.
There are two main points I think need to be set up for communication, which medium, and which language. In this case, the medium is also called “the protocol” and language is a set of conventions that have been agreed upon between the mobile team and server team. The common protocol is “HTTP” or “HTTPS”.
Now, pick up the phone and let's talk together.
Q: Is HTTP/HTTPS that I use to surf the web every day?
Yes, it is. It’s almost the same thing. The deferent here is what data you send to the server and what will be returning.
When you surf, the data returns is the HTML code, which is displayed as the website you read.
For the API, sometimes it is HTML, but in most cases, it will be more “programming structured data” such as XML or JSON, or binary.
Let's says a simple example, the mobile team need to get all user who is male and working in Manchester. The backend team can give a more generic API that supports fetching data of users who has specific gender and working place.
https://yourawesomeproject.com/get-users-have-gender-and-working-place?gender=male&working-place=manschesterThe response may be in JSON format like:
[
{"name": "Tom", age: "34"},
{"name": "Hallan", age: "35"}
]Q: Is it always HTTP/HTTPS for API
Absolutely not.
API is a generic term that is widely used in programming, not only for Client-server communication.
In terms of client-server communication, the answer is NO, too. Depending on the need of the product/project, the tech team can use another protocol. HTTP/HTTPS is the most common and easy way.
Q: What is deferent between HTTP vs. HTTPS
Nowadays, pure HTTP is not commonly used anymore, HTTPS is preferred.
In short, the difference is security. HTTPS means HTTP with Security.
For HTTP, the communication between client and server and be eavesdropped on or manipulated unauthorizedly.
HTTPS gives a more secure channel that gives your application a basic protection method. But keep in mind that it is not 100% warranty. The API can still be “hacked” in many ways even if you use HTTPS.
Q: How to turn our application which is using HTTP into HTTPS.
You can purchase an SSL certificate from a domain provider or an SSL certificate provider. But easier, ask your tech team to purchase an SSL certificate and ask them to use HTTPS.
Q: As you say, API with HTTPS supported is also can be hacked. How can we enhance security protection?
It is a quite complicated job, and you need a security expert to build it for you. Some basic questions you can ask your tech team to make sure at least you have basic protection:
- Does the API use “sig” or “token” to make sure the API is not alternated, duplicated on the fly, or authorized access/fetching data?
- Does the API have some protection such as WAF?
- Is there any kind of firewall used?
Q: My team also discusses the terms POST, GET, PATCH, PUT, and so on. How does it take part in the project?
As PM, you do not need to know deeply about this stuff.
Basically, POST for sending data to the server and GET for fetching data. The rest terms are optional.
Q: And what about errors 500, 404, and so on?
This is for HTTP/HTTPS communication. Data that returns from the server-side contains two things: the status and the data. To determine the status of the request, the list of status codes is pre-defined.
Some basic status codes:
- 200: success
- 400: the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing)
- 403: server understands the request but refuses to authorize it.
- 404: resource not found
- 500: internal server error
- 502: server is down
Find all list of codes here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
Q: Sometimes I see data is not correct or up-to-date, tech team says that data is cached? Is that right? And what is the solution?
Yes, caching is absolutely important for the system. Some data need a high-cost CPU to compute or take a lot of time to finish. To save cost, a part of data or whole data of a computing process can be cached — temporary storage for further use.
The cached data can be refreshed after a period, which calls TTL — time to live. Depending on the type of data and usage need, TTL may be long or short.
Tech team can you multi-tier cache — data is cached in multilayer such as in-memory, disk-cache, database cache, proxy cache, CDN edge cache … All those things make the cache control can be actually complicated.
Besides caching, the tech team can use the “load-balancing” technique to share the traffic. The system now is a group of connected nodes (server). The consequently is data from each node maybe can not sync together right-time. So you can see sometimes data is different every time you “refresh”.
There is no silver bullet. You have to compromise between to cost of cache management, the complexity of tech, and the application performance.
Q: And how about the “load-balancing” term?
Besides caching methodology, load-balancing is also very important and needs to be considered while designing the system.
Nowadays, you will see the tech team talk much about microservice design and horizontal scaling as key points of load-balancing.
In short, a load-balancer allows fine-grained configuration of how incoming traffic is distributed across nodes in the cluster that helps your system can handle a large number of user requests.
Instead of going deeply into the “load-balancing” term which is quite a technical term, as PM, I think you need to care more about the capacity/quality of the system. There are some questions you need to make clear with the tech team?
- How many users we can serve at the same time?
- Can our system serve users during peak time? And how the max capacity is?
- How does the system scale when the number of users is growing? A detailed plan of scale and cost.
IMO, it’s quite complicated enough for a single post. I will continue to go deeper into this topic in the next some posts.
Feel free to query me if you have any feedback or question.
