Every dev should know these API styles.
1. SOAP (Simple Object Access Protocol)
The OG that is still around, but mostly in legacy systems.
It has a client-server model like every other API.
Three things you should know about soap.
First: It uses XML for requests.
Let’s zoom in a little and see what the request looks like.
Here we are trying to get user info by ID:
Second: SOAP has only one endpoint.
Instead of querying different endpoints, you specify the function (GetUserInfo) to get the data you want.
The server code is basically a nested object (SOAP, aka Simple Object Access Protocol):
The server will run that function and return the user data.
Third: SOAP has a strict set of rules
It specifies what to send and how to send it.
For example, in the server, you have to write a WSDL that describes in detail what your API does, which looks like this:
SOAP is slow and painful to use.
So people created REST API.
2. REST (Representational State Transfer)
Unlike SOAP, REST API is just a set of guidelines.
It’s up to you, the developer, to implement the details.
So it’s much more flexible and easier to use.
The previous verbose XML request can be simplified into this:
REST API is a group of endpoints. Each endpoint accepts a specific request and response.
For a GET request, you just have to specify the endpoint you send the request to:
GET /users/123And in the server:
No WSDL. No bunch of nothing. Just a simple JSON response data.
Now you should understand why people say REST is lightweight and fast.
REST has 4 core traits:
Requests are HTTP
The data sent can be JSON, HTML, text, or more, and not just XML.
The communication is stateless. Meaning each request is independent and doesn’t know what happened before or after
Cacheable data
Rest API is great. It's still the most used API style today.
But the new cool kid is GraphQL.
3. GraphQL
In Rest API, endpoints decide the what data you get back.
In GraphQL, there is only one endpoint.
(Funny how we seem to go back a little bit)
The server first defines a schema that describes the types of data available.
And resolvers to handle the actual data fetching.
// 2. the backend logic
const resolvers = {
Query: {
getUserInfo: (_, { userId }) => {
return {
userId,
userName: "John Doe",
email: "[email protected]"
};
}
}
};Then the client writes queries based on that and specifies exactly what data they need.
query {
getUserInfo(userId: 123) {
userId
userName
email
}
}The selling point of GraphQL is that you can decide what data you want.
Don't need the email? Just remove it from your query:
query {
getUserInfo(userId: 123) {
userId
userName
}
}This makes frontend devs’ lives much easier.
The downside is maybe, you know, a little bit more work in the backend.
Lastly, we have WebSockets.
4. WebSockets
Traditional APIs suck at handling real-time communication.
So, WebSocket was created.
It uses the WS protocol.
First, you create a web socket in the client and make it listen for incoming events:
const socket = new WebSocket("ws://localhost:3000");
// When receiving a message
socket.onmessage = (event) => {
console.log("Server says:", event.data);
};
Then you do the same in the server:
const WebSocket = require("ws");
const wss = new WebSocket.Server({ port: 3000 });
wss.on("connection", ws => {
// Listen for client messages
ws.on("message", message => {
console.log("Received:", message);
// Echo the message back
ws.send("You said: " + message);
});
});
console.log("WebSocket server running at ws://localhost:3000");
Now the client and server have a persistent connection.
Both of them can send requests simultaneously without waiting for each other. This is called full duplex. Basically, like a phone call, where both parties can speak at the same time.
This makes it perfect for anything that needs constant, real-time updates, like a messaging app.
Fee from Anime Coders
PS: This email is inspired by one of your replies.
If you want to leave one as well, hit reply or take the poll below.
