model_driven_api 2.2.8 → 2.2.9

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 14519f57024c689e4c8014a89f9d9a0b1e632080e03b926331e1399eaa91190d
-  data.tar.gz: bb0936097178dd56f187952a2a8790952b940fbce2c609577c5854e97fca266b
+  metadata.gz: c52d5fb636dc5d7e3641c28b51a3456b8420ac9f91dcc2843a52d1b2ac14c9f1
+  data.tar.gz: 3611f35e1a6f99f545c8cd40136a0ae3a4b7ff7ddd5d904c8d9cd1ba19eab786
 SHA512:
-  metadata.gz: fbabff68ac85c2f8fd1da033419f7b24c3747b39c26ead781ce0626586d300e15ecd8ca7f7144922b0e2539ea2c938523c9e688fb400154d7619b3ef78a7fbb1
-  data.tar.gz: db518714c92aa0208aac7977f388a45e21afada104a612c16c52d1e4c2bce3aec206fbc024e3e3db2efbd72e4e93a8839bab050cb0ac8e8bd54474689350e715
+  metadata.gz: 57ee0c2b9c2505f6eb7c827c0c24fa8a10e3af9d07400d8ed8226be3a4d7a5caffc524052ab80ef3ba555b6119da555918135e1c376027cff83067fd9264d69b
+  data.tar.gz: 744eb2730193c381c31f023f3f095499f89725c0d40e932ed012f2593a4488a8a64a4fb3a6f69a336266b9648c9b72b1707a64a04966c8adb09161b0ab86c465

data/README.md

@@ -1,13 +1,33 @@
 # Model Driven Api
-I've always been interested in effortless, no-fuss, conventions' based development, DRYness, and pragmatic programming, I've always thought that at this point of the technology evolution, we need not to configure too much to have our software run, having the software adapt to data layers and from there building up APIs, visualizations, etc. in an automatic way. This is a first step to have a schema driven API or better model drive, based on the underlining database, the data it has to serve and some sane dafults, or conventions. This effort also gives, thanks to meta programming, an insight on the actual schema, via the info API, the translations available and the DSL which can change the way the data is presented, leading to a strong base for automatica built of UIs consuming the API (react, vue, angular based PWAs, maybe! ;-) ).
 
-Doing this means also narrowing a bit the scope of the tools, taking decisions, at least for the first implementations and versions of this engine, so, this works well if the data is relational, this is a prerequisite (postgres, mysql, mssql, etc.).
+## Goal
+
+To have a comprehensive and meaningful Model driven API right out of the box by just creating migrations in your rails app or engine. With all the CRUD operations in place out of the box and easily expandable with custom actions if needed.
+
+## TL;DR 5-10 minutes adoption
+
+1. Add this line to your application's Gemfile or as a dependency for your engine gem: ```gem 'model_driven_api'```
+2. Run from the shell: ```bundle```
+3. Add needed models, like: 
+  ```bash
+  rails g migration AddLocation name:string:index description:text:index
+  rails g migration AddProduct name:string:index code:string:uniq location:references
+  # Any other migration(s) you need... 
+  ``` 
+4. Run the migrations: ```rails db:migrate```
+5. Bring up your dev server: ```rails s```
+6. Use **[Insomnia](https://github.com/Kong/insomnia)** rest client to try the endpoints by importing [the API v2 tests](test/insomnia/ApiV2Tests.json) and editing the environment variables as needed.
+
+This will setup a *User* model, *Role* model, *Permissions* model and the HABTM table between these + any added model you created at the step 3.
+
+The default admin user created during the migration step has a randomly generated password you can find in a .passwords file in the root of your project, that's the initial password, in production you can replace that one, but for testing it proved handy to have it promptly available.
+
 
-# Goal
+I've always been interested in effortless, no-fuss, conventions' based development, DRYness, and pragmatic programming, I've always thought that at this point of the technology evolution, we need not to configure too much to have our software run, having the software adapt to data layers and from there building up APIs, visualizations, etc. in an automatic way. This is a first step to have a schema driven API or better model drive, based on the underlining database, the data it has to serve and some sane dafults, or conventions. This effort also gives, thanks to meta programming, an insight on the actual schema, via the info API, the translations available and the DSL which can change the way the data is presented, leading to a strong base for automatica built of UIs consuming the API (react, vue, angular based PWAs, maybe! ;-) ).
 
-To have a comprehensive and meaningful API right out of the box by just creating migrations in your rails app or engine.
+Doing this means also narrowing a bit the scope of the tools, taking decisions, at least for the first implementations and versions of this engine, so, this works well if the data is relational, this is a prerequisite (postgres, mysql, mssql, etc.).
 
-# v2?
+## v2?
 
 Yes, this is the second version of such an effort and you can note it from the api calls, which are all under the ```/api/v2``` namespace the [/api/v1](https://github.com/gabrieletassoni/thecore_api) one, was were it all started, many ideas are ported from there, such as the generation of the automatic model based crud actions, as well as custom actions definitions and all the things that make also this gem useful for my daily job were already in place, but it was too coupled with [thecore](https://github.com/gabrieletassoni/thecore)'s [rails_admin](https://github.com/sferik/rails_admin) UI, making it impossible to create a complete UI-less, API only application, out of the box and directly based of the DB schema, with all the bells and whistles I needed (mainly self adapting, data and schema driven API functionalities).
 So it all began again, making a better thecore_api gem into this model_driven_api gem, more polished, more functional and self contained.
@@ -18,44 +38,27 @@ So it all began again, making a better thecore_api gem into this model_driven_ap
 * **Custom actions** defined in model's concerns now are triggered by a do querystring, for example: ```/api/v2/:model?do=custom_action``` or ```/api/v2/:model/:id?do=custom_action```
 * Searches using Ransack can be done either by GET or POST, but POST is preferred.
 
-# Standards Used
+## Standards Used
 
 * [JWT](https://github.com/jwt/ruby-jwt) for authentication.
 * [CanCanCan](https://github.com/CanCanCommunity/cancancan) for authorization.
 * [Ransack](https://github.com/activerecord-hackery/ransack) query engine for complex searches going beyond CRUD's listing scope.
 * Catch all routing rule to automatically add basic crud operations to any AR model in the app.
 
-## Usage
-How to use my plugin.
-
-## Installation
-Add this line to your application's Gemfile:
-
-```ruby
-gem 'model_driven_api'
-```
-
-And then execute:
-```bash
-$ bundle
-```
+## API
 
-Or install it yourself as:
-```bash
-$ gem install model_driven_api
-```
-
-Then run the migrations:
-```bash
-$ rails db:migrate
-```
+All the **Models** of *WebApp* follow the same endpoint specification as a standard. The only deviations to the normally expected **CRUD** endpoints are for the **authenticate** controller and the **info** controller described below. This is due to their specific nature, which is not the common **CRUD** interaction, but to provide specifically a way to retrieve the **[JWT](https://jwt.io/)** or retrieve low level information on the **structure** of the API.
 
-This will setup a User model, Role model and the HABTM table between the two.
+### Return Values
 
-Then, if you fire up your ```rails server``` you can already get a jwt and perform different operations.
-The default admin user created during the migration step has a randomly generated password you can find in a .passwords file in the root of your project, that's the initial password, in production you can replace that one, but for testing it proved handy to have it promptly available.
+The expected return values are:
 
-## Consuming the API
+ - **200** *success*: the request performed the expected action.
+ - **401** *unauthenticated*: username, password or token are invalid.
+ - **403** *unauthorized*: the user performing the action is authenticated, but doesn't have the permission to perform it.
+ - **404** *not found*: the record or custom action is not present in the 
+ - **422** *invalid*: the specified body of the request has not passed the validations for the model.
+ - **500** *errors on the platform*: usually this means you found a bug in the code.
 
 ### Getting the Token
 
@@ -76,8 +79,8 @@ with a POST body like the one below:
 }
 ```
 
-This action will return in the header a *Token* you can use for the following requests.
-Bear in mind that the *Token* will expire within 15 minutes and that at each succesful request a new token is returned using the same *Token* header, so, at each interaction between client server, just making an authenticated and succesful request, will give you back a way of continuing to make **authenticated requests** without the extra overhead of an authentication for each one and without having to keep long expiry times for the *Token*.
+This action will return in the **header** a *Token* you can use for the following requests.
+Bear in mind that the *Token* will expire within 15 minutes and that at **each successful** request a ***new*** token is returned using the same **header**, so, at each interaction between client server, just making an authenticated and successful request, will give you back a way of continuing to make **authenticated requests** without the extra overhead of an authentication for each one and without having to keep long expiry times for the *Token*.
 
 Keep in mind that the Token, if decoded, bears the information about the expiration time as part of the payload.
 
@@ -89,14 +92,114 @@ Once the JWT has been retrieved, the **Authenticated Request**s must use it in a
 Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE1OTA3NzQyMzR9.Z-1yECp55VD560UcB7gIhgVWJNjn8HUerG5s4TVSRko
 ```
 
+### CRUD Actions
+
+All the interactions with the **Models** are **Authenticated Request** (see below for reference on **Getting the Token**), all the models have the following six **CRUD** actions and the **custom** actions defined for them in addition (see below for reference to custom actions in the **Schema** section of the **Info** controller):
+
+#### List
+
+Returns a list of all the records for the models specified by the expected fields as per **DSL** section below.
+Example request for **users** model:
+
+```bash
+GET http://localhost:3000/api/v2/users
+```
+
+#### Search
+
+Returns a list of all the records for the models specified by the expected fields as per **DSL** section below, the returned records are **filtered** by the **search predicates** you can find in the body of the request:
+Example request for **users** model:
+
+```bash
+POST http://localhost:3000/api/v2/users/search
+```
+
+Example of the body of the request (*q* means **question**, the *_eq* particle means **equals**, so in this simple example I'm looking for records which have the *id* attribute set to 1, mimicking the **Show** action below):
+
+```json
+{
+  "q":{
+    "id_eq": 1
+  }
+}
+```
+
+The complete documentation of the predicates that can be used is provided by the **[Ransack](https://github.com/activerecord-hackery/ransack)** library, the filtering, ordering, grouping options are really infinite.
+
+#### Create
+
+Creates a record for the specified **Model**.
+Validations on the data sent are triggered.
+Example request for **users** model:
+
+```bash
+POST http://localhost:3000/api/v2/users
+```
+
+Example of the body of the request:
+
+```json
+{
+  "user":  {
+    "email": "prova@example.com",
+    "admin": false,
+    "password": "prova63562",
+    "password_confirmation": "prova63562"
+  }
+}
+```
+
+#### Show
+
+Retrieves a single record as specified by the expected fields as per **DSL** section below.
+Example request for **users** model (retrieves the record with ID = 1):
+
+```bash
+GET http://localhost:3000/api/v2/users/1
+```
+
+#### Edit
+
+Changes the value of one or more attributes for the specified model. In the body of the PUT request you can just use the attributes you want to change, it's **not** necessary to use all the attributes of the record.
+Example request for **users** model with ID = 1:
+
+```bash
+PUT http://localhost:3000/api/v2/users/1
+```
+
+Example of the body of the request:
+
+```json
+{
+  "user": {
+    "email": "ciao@example.com"
+  }
+}
+```
+
+#### Delete
+
+Deletes the specified record.
+Example request for **users** model with ID = 1:
+
+```bash
+DELETE http://localhost:3000/api/v2/users/1
+```
+
+#### Custom Actions
+
+Are triggered by a **do** querystring, for example: `GET /api/v2/:model?do=custom_action` or `GET /api/v2/:model/:id?do=custom_action` respectively for a custom action which works on the entire records collection or a custom action which works on the specific record identified by :id.
+
 ### Info API
 
-The info API **api/v2/info/** can be used to retrieve general information about the REST API:
+The info API **/api/v2/info/** can be used to retrieve general information about the REST API.
 
 #### Version
 
-By issuing a GET on this api, you will get a response containing the version of the model_driven_api. 
-This is a request which doesn't require authentication, it could be used as a checkpoint for consuming the resources exposed by this engine.
+By issuing a GET on this api, you will get a response containing the version of *WebApp*. 
+This is a request which **doesn't require authentication**, it could be used as a checkpoint for consuming the resources exposed by this engine.
+
+Example:
 
 ```bash
 GET http://localhost:3000/api/v2/info/version
@@ -141,7 +244,7 @@ Something like this can be retrieved:
 
 #### Schema
 
-**Authenticated Request** This action will send back the *authorized* models accessible by the current user at least for the [:read ability](https://github.com/ryanb/cancan/wiki/checking-abilities). The list will also show the field types of the model and the associations.
+**Authenticated Request** This action will send back the *authorized* models accessible by the **User** owner of the *Token* at least for the [:read ability](https://github.com/ryanb/cancan/wiki/checking-abilities). The list will also show the field types of the model and the associations.
 
 By issuing this GET request:
 
@@ -199,7 +302,118 @@ You will get something like:
 }
 ```
 
-The *methods* key will list the **custom actions** that can be used in addition to normal CRUD operations, these can be bulk actions and anything that can serve a purpose, usually to simplify the interaction between client and server (i.e. getting in one request the result of a complex computations which usually would be sorted out using more requests). Later on this topic.
+The ***associations***: key lists the relations between each model and the associated models, be them a n:1 (belongs_to) or a n:m (has_many) one.
+The ***methods*** key will list the **custom actions** that can be used in addition to normal CRUD operations, these are usually **bulk actions** or any computation that can serve a specific purpose outside the basic CRUD scope used usually to simplify the interaction between client and server (i.e. getting in one request the result of a complex computations which usually would be sorted out using more requests).
+
+#### DSL
+
+**Authenticated Request** This action will send back, for each model, which are the fields to be expected in the returning JSON of each request which has a returning value.
+This information can complement the **Schema** action above output by giving information on what to expect as returned fields, associations and aggregates (methods) from each **READ** action of the **CRUD**.  It can be used both to *validate* the returned values of a **LIST** or a **SHOW** or to *drive* UI generation of the clients.
+
+By issuing this GET request:
+
+```bash
+GET http://localhost:3000/api/v2/info/dsl
+```
+
+You will get something like:
+
+```json
+{
+  "users": {
+    "except": [
+      "lock_version",
+      "created_at",
+      "updated_at"
+    ],
+    "include": [
+      "roles"
+    ]
+  },
+  "roles": {
+    "except": [
+      "lock_version",
+      "created_at",
+      "updated_at"
+    ],
+    "include": [
+      {
+        "users": {
+          "only": [
+            "id"
+          ]
+        }
+      }
+    ]
+  },
+  "role_users": null
+}
+```
+
+#### Translations
+
+**Authenticated Request** This action will send back, all the **translations** of *model* names, *attribute* names and any other translation defined in the backend.
+This can be used by the UI clients to be aligned with the translations found in the Backend.
+The locale for which the translation is requested can be specified by the querystring *locale*, it defaults to **it**.
+For **Model** translations, the ones used more, the key to look for is ***activerecord*** and subkeys **models** and **attributes**.
+
+By issuing this GET request:
+
+```bash
+GET http://localhost:3000/api/v2/info/translations?locale=it
+```
+
+You will get smething like (incomplete for briefness):
+
+```json
+{
+  "activerecord": {
+    "attributes": {
+      "user": {
+        "confirmation_sent_at": "Conferma inviata a",
+        "confirmation_token": "Token di conferma",
+        "confirmed_at": "Confermato il",
+        "created_at": "Data di Creazione",
+        "current_password": "Password corrente",
+        "current_sign_in_at": "Accesso corrente il",
+        "current_sign_in_ip": "IP accesso corrente",
+        "email": "E-Mail",
+        "encrypted_password": "Password criptata",
+        "failed_attempts": "Tentativi falliti",
+        "last_sign_in_at": "Ultimo accesso il",
+        "last_sign_in_ip": "Ultimo IP di accesso",
+        "locked_at": "Bloccato il",
+        "password": "Password",
+        "password_confirmation": "Conferma Password",
+        "remember_created_at": "Ricordami creato il",
+        "remember_me": "Ricordami",
+        "reset_password_sent_at": "Reset password inviata a",
+        "reset_password_token": "Token di reset password",
+        "sign_in_count": "Numero di accessi",
+        "unconfirmed_email": "Email non confermata",
+        "unlock_token": "Token di sblocco",
+        "updated_at": "Aggiornato il",
+        "username": "Nome Utente",
+        "code": "Codice",
+        "roles": "Ruoli",
+        "admin": "Amministratore?",
+        "locked": "Bloccato?",
+        "third_party": "Ente Terzo?"
+      },
+      "role": {
+        "users": "Utenti",
+        "name": "Nome",
+        "permissions": "Permessi"
+      },
+      "permission": {
+        "predicate": "Predicato",
+        "action": "Azione",
+        "model": "Modello"
+      },
+
+      [ ... ]
+}
+```
 
 ## Testing
 
@@ -208,7 +422,7 @@ Once loaded the tests inside the insomnia application, please right click on the
 
 ## TODO
 
-* Integrate a settings gem
+* Add a Trust management for API consumers, to have some low level interactions happen between API client and server done without the need for giving a USERNAME and a PASSWORD.
 
 ## References
 Thanks to all these people for ideas:

data/lib/model_driven_api/version.rb

@@ -1,3 +1,3 @@
 module ModelDrivenApi
-  VERSION = '2.2.8'
+  VERSION = '2.2.9'
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: model_driven_api
 version: !ruby/object:Gem::Version
-  version: 2.2.8
+  version: 2.2.9
 platform: ruby
 authors:
 - Gabriele Tassoni
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2020-06-08 00:00:00.000000000 Z
+date: 2020-10-26 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: thecore_backend_commons