<aside> 💡 Please read the General Developer Documentation first

</aside>

Overview

In this section document I will be covering how the core service API works, future features to implement, and how to use the API. The best way to discover how the core service works passed this document is definitely by exploring the code, playing with the API with Postman, and seeing how the API is used on the Main Website.

How it Works

Core Service is a sever-less API, I build with Node and Express, then hosted on Firebase Functions. The purpose of Core Service is to allow our Main Website to access the important cloud services it needs to run. In this case, our Core Service connects us to the Firestore database, Firebase Authentication, and Firebase Storage.

How to Use

• When making API calls from Main Website , we use the fetch API (look online for some good tutorials and documentation for that)
  • Otherwise, axios is another good option for making API calls from a frontend
• It is recommended that to make API calls for testing and development purposes that you use Postman.
  • When deploying the API to Firebase functions or locally with the Firebase emulator, a URL to call the API will be given

Routes

The following routes are appended to the end of the URL to make the calls to the API

The GET, POST, DELETE indicates it's request method and protected routes are indicated and discussed below.

Users

<aside> 💡 Currently Admin login only

</aside>

POST
/login

Thumbnails

POST - PROTECTED
/thumbnails/simulators

POST - PROTECTED
/thumbnails/simulators

Simulators

GET
/simulators

POST - PROTECTED
/simulators

DELETE - PROTECTED
/simulators/:simulatorId

Workshops

GET
/workshops

POST - PROTECTED
/workshops

DELETE - PROTECTED
/workshops/:workshopId

<aside> 💡 Protected routes simply mean that authorization is required. Which is done by creating an header tag in the Header tab, with key: Authorization and value: Bearer token (this token is the response received from a successful login request)

</aside>

<aside> 💡 :workshopId and :simulatorId are variables which identify which simulator or workshop to delete

</aside>

<aside> 💡 In the example above, the simulator with ID: todelete is to be deleted with this request

</aside>

Request Body

The body of the request is data you sent to the API. It is required in a couple routes on the Core Service notably the login route and any route to add a new piece of content

<aside> 💡 The request body is typically of the raw JSON type, except in uploading files case (which you will see below).

</aside>

<aside> 💡 The hidden header Content-Type should have a value of application/json

</aside>

Below are samples of how to structure your request body for each of the POST routes. Follow these exactly for the Core Service