API Generator SPECS

[app-generator]

• REQ_01 - Models defined in apps/models.py

  • NOTE: Models should be migrated in the database

• REQ_02 - User runs the command python manager gen_api - Operation Checks:

  • REQ_02_1 - model exists in the DB
  • REQ_02_2 - model enabled in the CONFIG

• REQ_03 - The code is generated in apps/api

  • REQ_03_1 - Old code is removed
  • REQ_03_2 - New definitions are added

• REQ_04 - API Engine:

  • DRF

• REQ_04 - API Permissions:

  • REQ_04_1 - Common users are able to edit / delete / list / their items
  • REQ_04_2 - Superusers have full power over CRUD operations
  • REQ_04_3 - GET requests are free (item + get all)

[app-generator]

Hello @Mortrest

I just added detailled requirements. Let me know if something is not clear.

Ty

[Mortrest]

Hello

1. What is the difference between this project and Django Dynamic API project?
2. Get, Edit, Delete and Get processes do by Postman?

[app-generator]

In this project, the code should be generated based on the model types.

The drawback of the previous implementation is the runtime overload injected by the process. Being abstract, the app always scans the definition and applies the generic processing.

In this project, the serialization code should be specific to the model definition, like a hardcoded implementation tied to the models.

The abstract layer shouldn't be the solution.

So, the flow is this:

• define the model
• migrate the DB to create the model
• activate the API generation for this model in CFG
• generate the code specific to the model
  • serialization etc, just like in the manual coding
• When API is consumed (via POSTMAN)
  • GET requests are public
  • Mutating requests (Create, Delete, Update) (requires authorization) will take care of the requester ID
  • ordinary users can mutate their own items
  • superusers can mutate all items

Let me know if something is missing.

[Mortrest]

Hello I implemented generating api (without authorization). but for authorization, you want to use django rest jwt?

[app-generator]

Hello @Mortrest

Ty for your work. Regarding the authorization, can you tell me what options we have?

For the Dyn API project I wrote a simple checker that decorates the API views. https://github.com/app-generator/priv-devtool-django-dynamic-api/blob/master/apps/helpers.py

Before choosing a solution, is important to keep in mind the use cases:

• API is used by the app users
  • being authenticated we can check their permission using the decorator
• API might be used by 3rd parties (POSTMAN or a React app consumer)
  • in this case, we need a token associated with each account.

Let me know all possible solutions. Ty!

[Mortrest]

Django Rest Framework has an option to have 2 authentication methods (token-base and basic-authentication) together. It seams to be best solution.

[Mortrest]

There is a point in your saying about mutating requests. You said: ordinary users can mutate their own items superusers can mutate all items If we want this, we should force users to add a creator field to each model (foreign key to User). I think this forcing is not good. Do you have another opinion?

[app-generator]

Hello @Mortrest

Mutating requests

We can skip this constraint for the moment (no creator field) and keep the mutating operations the same for all auth users (superusers and ordinary users).

Being the first iteration of the module, without real users feedback, is a good idea to keep things as simple as possible.

DRF Auth layer

I'm ok to use the dual auth layer for DRF, but we need to document both cases in the README file.

Also, a sample for the basic auth should be coded in the main dashboard.

Ty @Mortrest

[Mortrest]

Hello Implementation Almost over. I added some description to README.md to describe how can work with app. Please take a look.

[app-generator]

Ty @Mortrest I will validate soon the feature. 🚀🚀

[app-generator]

P.S. @Mortrest please take a look at #4 ty

[app-generator]

Hello @Mortrest

Development moved to: https://github.com/app-generator/django-soft-ui-dashboard

[app-generator]

Validated & Closed.