Introduction
Welcome to the documentation for Mubarti, a comprehensive playground management system. Mubarti is designed to streamline the management and reservation of playgrounds, providing a robust solution for both administrators and users. This project leverages a modern tech stack to deliver a seamless experience across different platforms.
Mubarti utilizes Django and REST API for its backend infrastructure, ensuring a scalable and efficient system. The backend is accessed by a mobile application developed with Flutter and a web application built using React. This documentation focuses on the backend API, detailing its structure and functionality.
Backend Structure
The backend of Mubarti is organized into four main apps, each handling a distinct aspect of the system:
1- Accounts App: This app manages user authentication, providing secure login and registration functionalities.
2- Admin Management App: Responsible for handling both admin and player profiles. and management of user roles and personal information.
3- Facility App: Central to the system, this app oversees facility management It manages details about each facility and its associated playgrounds and categories, ensuring accurate tracking and administration of available resources.
4- Reservation App: This app handles the playground booking process and match creation. It enables users to reserve playgrounds and schedule matches, ensuring an organized and efficient booking system.
Conventions
The base URL to send all API requests is https://api.mubarti.streamline.com.ly. HTTPS is required for all API requests.
The Mubarti back-end API follows RESTful conventions when possible, with most operations performed via GET, POST, PATCH, and DELETE requests on page and database resources. Request and response bodies are encoded as JSON
Pagination
In the Mubarti project, pagination is designed to efficiently manage and display large datasets across multiple pages. The default pagination settings are configured to present 10 results per page, providing a balanced view of data without overwhelming the user interface.
The pagination system allows both the mobile application side and the web application side to customize their view of the data by specifying the number of results they wish to see per page. This flexibility is achieved through the page_size and page. parameter included in the request.
Supported Endpoints
| HTTP method | Endpoint |
|---|---|
| Get | List of Users |
| Get | List of Facilities |
| Get | List of Playgrounds |
| Get | List of Matches |
Responses
When the endpoint support pagination then the web/mobile apllication will receive the response below:
| Field | Type | Description |
|---|---|---|
| status | boolean | This field indicates whether the request is successful or not. true if the request is successful. Otherwise, false. |
| message | string | This field helps on explaining the response. |
| data | list | the list of data requested. |
| has_more | boolean | Whether the response includes the end of the list. false if there are no more results. Otherwise, true. |
Parameters for paginated requests
GET requests accept parameters in the query string.
POST requests receive parameters in the request body.
| Field | Type | Description |
|---|---|---|
| page_size | integer | The number of items from the full list to include in the response. Default: 10 Maximum: 100 The response may contain fewer than the default number of results it based on the total results. |
| page | integer | This prameter helps determine the page number. |