Add Masonite API back to core

Need to look at the Masonite API package and merge that into this one as we did with Masonite-scheduler.

This will need to be spec’d out though in order to make sure we hit all the core requirements when we do the back port.

Feature Spec

Masonite API

This product spec details the feature requirements and technical specifications for the adding an API feature to Masonite.

Summary

Masonite 2 had very minimal API support. It was primary designed to be used because a small group of people needed a few features and I built it for them. The Masonite features used to be inside the Masonite codebase but was removed to be its own package. Ever since we moved it to its own package, it has caused more issues than it helped. Because of this, will be moving Masonite API features back into the codebase for the Masonite 4 release.

Summary of features include:

• Authentication classes (for getting tokens)
• API Guard
• Authentication Middleware to verify token
• Resource classes
• Authentication Drivers (token)
• Hashing tokens

Technical Specifications

Resource Class - Resource classes will basically be controllers that return a user model. A user model will then be serialized by the response class. We should be able to support resource methods which are:

• Index - show a collection of all routes
• Show - Show an individual record
• Store - Create a new record
• Update - Updates an existing record
• Delete - Deletes a record

Authentication Controller - Possibly may skip this. Low priority. Class to be used to pass an email and password which, if good, saves an API Token in the users table and returns the token as a response. Can be a basic controller with a single method.

API Guard - This is a guard which will be used to fetch the user by API token and attach it to the request class. We may need to put the authentication stuff in this guard as well.

Authentication Drivers - These drivers should return a boolean if the user should continue. We can use this in a middleware to check if we need to throw some kind of authentication error.

Hashing tokens - Anytime we store a token in the database we may want to hash it inside the database. Just an added security measure.

Authentication Middleware - We should be able to add a middleware, possibly in a new api middleware stack. This middleware will return an authorized error or continue to the request.

[josephmancuso]

@girardinsamuel we need to figure out how this is going to work … We need:

• Serializers - to serialize into different types of data (JSON, XML, etc).
• Authorization classes - Token authorization, JWT auth, etc
• Resource class - normal CRUD stuff.
• Can take ideas from this https://laravel.com/docs/8.x/passport although Passport is full oauth2 support. we’re just doing authentication and authorization, and serializing here

[josephmancuso]

We need to start coming up with an advanced product spec on what this is actually supposed to do. Should explore other frameworks