API Model for Gaming Service
Let's learn about the data entities and message formatting for the gaming API.
We learned the workflow and architectural layout of the game system in the last lesson. This lesson will cover the functional requirements of our game service in terms of data entities, message formats, and API endpoints. We’ill also discuss how event notifications are communicated between players and the game server at the end of this lesson.
Note: We assume that the reader has gone through the design problems mentioned in the prerequisite section in the first lesson. Therefore, we won’t discuss certain functionalities like chat, audio conferencing, payments, and alerts to keep the contents of this lesson concise.
Let's start by learning about the common terms we’ll use in this lesson.
Glossary of Abbreviations and Terms
Notation | Description |
ZC | Acronym for zone controller or cluster controller |
GS | Acronym for the game server |
Game room | A game session being simulated on a game server |
Private room | Isolated rooms created by players to play games with specific players |
Base URL and API endpoints
For all the RESTful API requests, we use the base URL shown below:
The game API supports many features, so we list some common operations and their associated endpoints in the following illustration:
In the above illustration, each main category describes different supported functionalities. Let's discuss them briefly below:
Matches: This category includes requests related to matches such as obtaining available matches, joining a match, etc. ...