Getting Started

The developer documentation you need to getting started with the Elentra API.

Need help getting started for Elentra Platform development? Please see our Elentra Developer Getting Started Guide.

The architecture of the API

The primary technologies that are used to create the API are:

Caffeinated Modules

Caffeinated Modules is a Laravel plugin which provides a way to bring stand-alone plugins into the Laravel installation. This allows for specific parts of the API to be turned on or off depending on the requirement of the project, and encapsulates functionality for different parts of the data model. In the longer term, it may allow the API to be composed at build time to only include the specific sections of the data model that are needed, or for schools to provide their own modules to override the defaults provided by the Elentra project. A good example of where this would be required is for Authentication, so that schools can implement login functionality that is unique to their institution while retaining the other standard modules from the Elentra core.

Laravel Concepts

When working with the API, you may need to create or include parts of the Laravel framework. At various times in the development process, you may have to create or configure one or more of these things.

  1. Authentication - The authentication service provider takes care of logging a user into the system. Users must login (using some specific API endpoints) and this will return a token which the user can then attach to subsequent requests to the API

  2. Authorization - Authorization ensures that the resource (data) the user is asking for is something that user is allowed to see. So a student may be able to see their own grades, but not the grades of someone else.

  3. Routes - A route defines a URL that the API supports, and associates with the route the controller that is used to handle the request

  4. Request - When an API call reaches Laravel a request is created, which contains all the details about the request. A request will be evaluated against the available routes, and processed and passed to the appropriate controller.

  5. Response - Once a Request has been processed in the controller, a Response is created, to return the status of processing and the data, if any, that is to be passed back to the calling API.

  6. Controller - Understands what to do with a specific route, based on the HTTP request type (GET, POST, PUT, DELETE) and the parameters provided. The controller's function is to ensure the request has the appropriate inputs, that the user who is requesting the information is allowed access, and then to fetch the requested data and return it as a response in JSON format, with an appropriate response code that tells the caller the status of the request.

  7. Middleware - When routes are defined, they may be assigned specific middleware that will be run on that route. An example of middleware would be an authentication middleware that ensures that the requests includes a valid token and if valid, setting up the user's configuration within the API. When operating on requests, Middleware can be set to run before processing the request is handed off to the controller, or after the controller has constructed the response, but before the response is returned.

  8. Eloquent - Eloquent is the Object Relationship Manager (ORM) of Laravel which allows the API to read and write data to the Elentra databases.

  9. Models - Models are otherwise known as Eloquent Models, and refer to a file that reads or writes from a specific database table. This can include information about what other tables are related to the subject table, and how those relationships are defined.

  10. Scopes - Scopes allow you to define specific rules when accessing a database table, for example to always select 'active' entries. Using them simplifies the database queries with the model itself

  11. Service Providers - Service Providers are responsible to enabling components of the API, such as the database, validation and routing.

  12. Gates and Policies - When authorizing access to resources, Gates and Policies provide two ways to achieve the required logic. Gates are best suited to simple authorizing via closures, while Policies allow a more complex ability to use models or resources.

  13. Rules - It is possible to define custom validation rules to use when processing requests. For example, validating if a start date is less than an end date.

Last updated