Lay down foundation for the API

[Mubeen142]

With this PR I am laying down the foundation for the v1 API.

Current Endpoints:

• Get, create, update and delete users
• Get all servers
• Get all sites

This API uses the conventional HTTP standards, returns correct HTTP status codes and has a good structure. It is also nicely integrated within the code and uses the same workflow (Actions, Validation, Models, etc...)

The API also allows you to filter, sort and include data

Include, Filter, Sort and Date:

domain.com/api/v1/users?include=projects,servers,scripts This will return users including all their projects, servers and scripts. You can keep passing additional relations.

domain.com/api/v1/users?filter[role]=admin&filter[timezone]=europe The filter method allows you to filter users based on given parameters.

domain.com/api/v1/users?sort[created_at]=desc Sort allows you to sort by a specific column. Supported operators are asc, desc and random

domain.com/api/v1/users?date=30days The date method allows you to filter users created between certain days. You can pass today, yesterday, 3-7-14-30-90days and custom dates using ?date=YYYY-MM-DD,YYY-MM-DD

And ofcourse you can use filters, sorts, includes and date in combination. You can also pass an per_page parameter.

This logic is consistent throughout all API endpoints that return the full collection.

Creating API Keys

Users can create API keys on /settings/api-v1. I have not yet added the menu to the sidebar.

More Details

Other methods, such as creating, updating, deleting using the API go through Actions. Below is an example:

    try {
        $user = app(CreateUser::class)->create($request->input());
    } catch (\Exception $error) {
        if($error instanceof ValidationException) {
            return response()->json(['success' => false, 'errors' => $error->validator->errors()->all()], 422);
        }

        return response()->json(['success' => false, 'errors' => [$error->getMessage()]], 500);
    }

    return response()->json(['status' => true, 'data' => $user], 201);

This ensures that validation errors are returned nicely, better error handling quicker workflow, and one codebase.

Left Todo

• Hash or Encrypt API keys before storing them
• Only allow admins to create API keys
• Limit API keys to given IP addresses
• Add the rest of the endpoints

[saeedvaziry]

Thanks @Mubeen142 for the PR. I'll be AFK the whole week. Will check it on the weekend.

[saeedvaziry]

ok. a few comments to start this,

1. We don't need an API to manage users
2. API Keys should be managed by admins only on the settings (/settings/api-keys) and would be good to have them as tables in the UI
3. lets not build a GraphQL with Rest API. we want to only cover a few required things rather than building something complicated with filters and etc
4. The last step will be writing tests to keep our coverage still around 70%.

[Mubeen142]

1. Why not?

The main reason I built this API is to remotely create users and give them access to sites.

2. Yeah I already mentioned this in the todos

3. I have already written all the backend code required for the API. The API has a good structure and follows industry standards.

4. Please rephrase this, I don't quite understand what you mean.

With this PR I wanted to create the structure for the API. The first API will be under v1. Its quite easy to add new endpoints. You add the endpoint in routes/v1.php and then add the controller method that can be copied from the endpoints that already exists.

[saeedvaziry]

1. Because servers are based on projects. we want to manage projects rather than users. We don't want every user to be able to have an API key but we want every vito instance to be able to have API keys.

2. It's about maintainability. we want it simple and easy to maintain.

3. I don't see any tests in your PR.