RESTTful API description - ppouke/PWP GitHub Wiki

Important information for Deadline 1

‼️  This chapter should be completed by Deadline 1 (see course information at Lovelace)


📑  Chapter summary This chapter must provide a good overview of the Web API that your group is going to develop during the course. You should not focus in implementation aspects such as database structure, interfaces or the request/responses formats. We recommend that you look into existing APIs (see Related work below) before writing the description for your own API.

In this Chapter you must describe JUST the RESTful API, NOT THE CLIENT. Remember that client and Web API should be totally decoupled.

Chapter GOALS:

  1. Understand what is an API
  2. Describe the project topic API
  3. Describe how the API will be used in the project


✔️     Chapter evaluation (max 7.5 points) You can get a maximum of 7.5 points after completing this Chapter. More detailed evaluation is provided after each heading.

RESTful API description

Overview


📑  Content that must be included in the section

Describe the Web API briefly and comment which is the main functionality that it exposes to clients. Focus in the Web API not in the application which is using this API. Take into account that in the end, a WEB API is an encapsualted functionality as well as the interface to access that functionality. This section CANNOT include a description of an application or client that uses the API.

Justify also why you want to implement this API. Comment why a developer would like to integrate this API into their application. Try to "sell" the API to your potential customers.

A really short version of an overview for the RESTful Web API could be:

“The discussion forum Web API offers different functionalities to structure non-real-time conversations among the people of a group about topics they are interested in certain topic. Messages are grouped in Threads, that at the same time are grouped in Topics. The messages are accessible to anyone, but posts can only be created by providing credentials of a registered user [...] Clients using this service may implement applications similar to [...]“

Remember: The general description IS NOT just a description of the functionality. Try to market your API to potential customers.



✔️     Evaluation criteria(max 1.75 points) You can get a maximum of 1.75 points in this section
  • The description is clearly written and explains what the API is for: 0.5
  • The description includes a clear justification of why this project is useful. Why do you want to build this API:
  • 0.5
  • The description describes an API - not an application or client: 0.75
    • This means that the description is written in terms of the functionality it makes available for clients, and internal working of the API
    • tip: don't think about human users when writing the description - think about machines

✏️ The API will provide access to view and play games of Blokus using HTTP requests. Users can request available games and join them. The state of the game can be requested and turns can be taken.

This project is implemented with an API due to the increased flexibility it gives in creating game environments for the blokus game. With this, clients can be created individually and originally without the worry of their incompatibility with each other. Thus we enable a way to remotely play the game of blokus, regardless of distance or hardware.

Main concepts and relations


📑  Content that must be included in the section Define the main concepts and describe the relations among them textually. Roughly, a concept is a real-world entity that is expected to be of interest to users. This section will be used in Deadline 3 to generate the list of resources. Students should remember that some of the concepts might not be a resource by themselves, but just a part of it (resource property). In this section, students should not describe the RESTful resources, but identify which are the main ideas of the API. Do not forget to include the relations among the concepts.

A description of the main concepts for the Forum API could be:

"The API permits users send messages. The forum contains a list of categories and a list of users. Each category specifies a name, a description and a thread. A thread is [...]The forum may contain 0 or more categories… Each category may have 0 or more threads… Users can write and read messages to a forum thread. A user has a profile, basic information, activity information (stores, for instance, all the messages sent by a user, the messages marked as favorites). [...]The user history contains information of the last 30 messages sent by the user.[…]"

Include a diagram which shows easily the relations among concepts.

This section is important because it outlines the concepts that you will later implement. In particular, the diagram defined here will follow you throughout the project report and you will be adding more details to it.



✔️     Evaluation criteria(max 1.5 points) In this section you can get a maximum of 1.5 points:
  • Concepts are named and described: 0.5
  • Relations among concepts is clear: 0.5
  • A diagram that shows relations between concepts is provided: 0.5

✏️ The API allows requesting all available games. Based on the given list, users can join or create a game. Within a game, users have access to all the information you would in a face-to-face game session. This includes the state of the board, and for each player, blocks that are available. In addition, users can of course see whose turn it is. During their turn, users can modify the game state by placing a block.

API uses


📑  Content that must be included in the section Describe at least two clients that could use your Web API. You must explain here which is the functionality provided by the client, and how use the Web API to implement this functionality.


✔️     Evaluation criteria(max 1.75 points) In this section you can get a maximum of 1.75 points
  • The client descriptions are written clearly and explain what they are for: 0.75
  • Descriptions outline what parts of the API each client uses, and how: 0.5
  • At least two more examples of clients are provided (1-2 sentences per client):0.5

✏️ A typical client to use this API would be one that allows its user to play the game intuitively. This would require at least requesting the state of a specified game, visualizing it, then offering a way to place any available blocks in any desired and legal way. Most likely clients would also want to offer an interface to view, join and create games as well. Overall, a typical client would likely want to implement all of the functionality offered by the API.

Alternatively, a client could be made just to monitor the available games, or perhaps to automatically create a game at a certain time.

Related work


📑  Content that must be included in the section Find at least one API that resembles the functionality provided by yours. Explain in detail the functionality provided by the API. Classify the API according to its type (RPC, CRUD REST, pure REST, hypermedia driven ...) justifying your selection. Provide at least one example client that uses this API.

The purpose of this task is to get more familiar with what an API is. This will be helpful in describing your own API. Therefore, it is recommended to do this section after you have decided the topic of your project but before writing your API description.



✔️     Evaluation criteria(max 2.5 points) You can get a maximum of 2.5 points in this secton:
  • The selected API is similar or related to the project topic: 0.5
  • The API classified correctly, and is described in terms of offered functionality: 1.0
  • An example of a client that uses this API is provided, explaining briefly what it does: 0.5
  • An additional API is provided 0.5

✏️ An API similar to ours in function is the API for Online Go. The API looks to be using REST API based on the architecture of the URLs showing statlessness. The API offers multifaceted functionality. Firstly, it allows the listing and filtering of games, getting a game, and the ability to commit actions in the game such as pause, move or resign.
It also gives additonal meta functionality such as to give/post meta information of players' details, player groups and player torunaments. An example of the usage of this API can be found at onlinge-go.com, which uses this api in a browser based application form playing GO. It fully implements the functionality offered, allowing for groups, tournaments and puzzles, all communicated with thorugh the API.

Something simpler but with similar intent is the Chess Gallery Game Reference API, which intends to allow the fetching of a gallery of played games from a database to a client.

Resources allocation

Task Student Estimated time
Writing this Elmeri 3 hours
Writing this Sakaria 3 hours
Planning the API Everyone 3 hours
⚠️ **GitHub.com Fallback** ⚠️