Must Know API Structure for Web Developers (with example)
Calling APIs between services is one of the most common tasks in the web development world. Here are some examples to show how these API structures work. RESTful This is the most commonly used API style in web development. It is easy to use; just make an HTTP call to the resource you want, and you'll get it! The learning curve is smooth. Here's an example of how to display GitHub emojis in your browser. Websocket If you want your client to receive messages from the server, then you should choose WebSocket. The server can push messages to clients proactively. In this example, you send a WebSocket message to echo.websocket.org, and it will respond with an identical message to you. GraphQL GraphQL is similar to RESTful APIs except you can customize the response data structure from the client side. In this example, you get information about a Pokémon by entering its name. I tell the server to return the ID, height, weight, base happiness, and capture rate. You can ask for more information by editing the query method. Webhook Webhook is an event-driven communication between different applications. The webhook service sends an HTTP POST request to a predefined URL when an event is triggered. It can be used with your CI/CD workflow. The GitHub bot is built based on webhooks too. In this example, I use smee.io to redirect my webhook events. For demo purposes, the event sender and receiver are in the same application. But in the real world, they are two applications on two different servers. The trigger endpoint sends a webhook message to smee.io, and then smee.io redirects this message to the receiving endpoint. You can fork the sandbox to customize the message. Summary RESTful API Architecture Style: Based on HTTP protocol, using standard HTTP methods Data Format: JSON or XML Communication Workflow: Client sends HTTP request Server returns response WebSockets Architecture Style: Bidirectional communication, establishes persistent connection Data Format: Text or binary data Communication Workflow: Client and server establish persistent connection Real-time communication GraphQL Architecture Style: Query language, client specifies required data structure Data Format: JSON Communication Workflow: Client sends query request Server returns required data Webhook Architecture Style: Event-driven, server sends HTTP request to specified URL Data Format: JSON Communication Workflow: Event occurs Server sends HTTP request to client Reference https://blog.bytebytego.com/p/ep49-api-architectural-styles https://pokeapi.co/docs/graphql https://github.com/graphql-kit/graphql-apis
Calling APIs between services is one of the most common tasks in the web development world. Here are some examples to show how these API structures work.
RESTful
This is the most commonly used API style in web development. It is easy to use; just make an HTTP call to the resource you want, and you'll get it! The learning curve is smooth.
Here's an example of how to display GitHub emojis in your browser.
Websocket
If you want your client to receive messages from the server, then you should choose WebSocket. The server can push messages to clients proactively.
In this example, you send a WebSocket message to echo.websocket.org, and it will respond with an identical message to you.
GraphQL
GraphQL is similar to RESTful APIs except you can customize the response data structure from the client side.
In this example, you get information about a Pokémon by entering its name. I tell the server to return the ID, height, weight, base happiness, and capture rate. You can ask for more information by editing the query method.
Webhook
Webhook is an event-driven communication between different applications. The webhook service sends an HTTP POST request to a predefined URL when an event is triggered. It can be used with your CI/CD workflow. The GitHub bot is built based on webhooks too.
In this example, I use smee.io to redirect my webhook events. For demo purposes, the event sender and receiver are in the same application. But in the real world, they are two applications on two different servers.
The trigger endpoint sends a webhook message to smee.io, and then smee.io redirects this message to the receiving endpoint. You can fork the sandbox to customize the message.
Summary
RESTful API
- Architecture Style: Based on HTTP protocol, using standard HTTP methods
- Data Format: JSON or XML
-
Communication Workflow:
- Client sends HTTP request
- Server returns response
WebSockets
- Architecture Style: Bidirectional communication, establishes persistent connection
- Data Format: Text or binary data
-
Communication Workflow:
- Client and server establish persistent connection
- Real-time communication
GraphQL
- Architecture Style: Query language, client specifies required data structure
- Data Format: JSON
-
Communication Workflow:
- Client sends query request
- Server returns required data
Webhook
- Architecture Style: Event-driven, server sends HTTP request to specified URL
- Data Format: JSON
-
Communication Workflow:
- Event occurs
- Server sends HTTP request to client
Reference
https://blog.bytebytego.com/p/ep49-api-architectural-styles
https://pokeapi.co/docs/graphql
https://github.com/graphql-kit/graphql-apis