model_driven_api 2.2.4 → 2.2.9

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f796ea92049910892b48c1904c58192bb7a4b0021a0c0beef89c8e6106f7f64b
-  data.tar.gz: 5054f69acc854b47ab9a5825bb950d035882b05ea6285b81592989ab31d29343
+  metadata.gz: c52d5fb636dc5d7e3641c28b51a3456b8420ac9f91dcc2843a52d1b2ac14c9f1
+  data.tar.gz: 3611f35e1a6f99f545c8cd40136a0ae3a4b7ff7ddd5d904c8d9cd1ba19eab786
 SHA512:
-  metadata.gz: bbea75413aa62fceddd25f003e23fd6ec16a37f7027be2af549e2f565d91fd8ad8ef93dc07e2bb5cb8b8121aeaf276370ec649222dec8b4893c87a815c4e8a73
-  data.tar.gz: 871479573af6861b9c0aaf9d323668aab7f75afc68452501dd9c1d9253a96cdfc90cd74891e46e0273dfa0abd14357260fe79ab0ffebc92a11766baf2fae28b5
+  metadata.gz: 57ee0c2b9c2505f6eb7c827c0c24fa8a10e3af9d07400d8ed8226be3a4d7a5caffc524052ab80ef3ba555b6119da555918135e1c376027cff83067fd9264d69b
+  data.tar.gz: 744eb2730193c381c31f023f3f095499f89725c0d40e932ed012f2593a4488a8a64a4fb3a6f69a336266b9648c9b72b1707a64a04966c8adb09161b0ab86c465

data/README.md

@@ -1,86 +1,205 @@
 # 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
 
-# Goal
+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.
 
-To have a comprehensive and meaningful API right out of the box by just creating migrations in your rails app or engine.
+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.
 
-# v2?
+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.
+
+
+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.).
+
+## 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.
 
-# Standards Used
+## What has changed
+
+* Replace v1 with **v2** in the url
+* **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
 
 * [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.
+## API
+
+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.
+
+### Return Values
 
-## Installation
-Add this line to your application's Gemfile:
+The expected return values are:
 
-```ruby
-gem 'model_driven_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
+
+The first thing that must be done by the client is to get a Token using the credentials:
+
+```bash
+POST http://localhost:3000/api/v2/authenticate
 ```
 
-And then execute:
+with a POST body like the one below:
+
+```json
+{
+	"auth": {
+		"email": "<REPLACE>",
+		"password": "<REPLACE>"
+	}
+}
+```
+
+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.
+
+#### Authenticated Requests
+
+Once the JWT has been retrieved, the **Authenticated Request**s must use it in a header of Bearer Type like this one:
+
+```
+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
-$ bundle
+GET http://localhost:3000/api/v2/users
 ```
 
-Or install it yourself as:
+#### 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
-$ gem install model_driven_api
+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
+  }
+}
 ```
 
-Then run the migrations:
+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
-$ rails db:migrate
+POST http://localhost:3000/api/v2/users
 ```
 
-This will setup a User model, Role model and the HABTM table between the two.
+Example of the body of the request:
 
-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.
+```json
+{
+  "user":  {
+    "email": "prova@example.com",
+    "admin": false,
+    "password": "prova63562",
+    "password_confirmation": "prova63562"
+  }
+}
+```
 
-## Consuming the API
+#### Show
 
-### Getting the Token
+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):
 
-The first thing that must be done by the client is to get a Token using the credentials:
+```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
-POST http://localhost:3000/api/v2/authenticate
+PUT http://localhost:3000/api/v2/users/1
 ```
 
-with a POST body like the one below:
+Example of the body of the request:
 
 ```json
 {
-	"auth": {
-		"email": "<REPLACE>",
-		"password": "<REPLACE>"
-	}
+  "user": {
+    "email": "ciao@example.com"
+  }
 }
 ```
 
-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*.
+#### 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
@@ -125,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:
 
@@ -183,20 +302,130 @@ 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
 
 If you want to manually test the API using [Insomnia](https://insomnia.rest/) you can find the chained request in Insomnia v4 json format inside the **test/insomnia** folder.
-In the next few days, I'll publish also the rspec tests.
+Once loaded the tests inside the insomnia application, please right click on the folder, then in the menu select *</> Environment* and change ```base_url```, ```email``` and ```password``` as needed to set them for all the subsequent actions.
 
 ## TODO
 
-* Integrate a settings gem
-* Add DSL for users and roles
+* 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:
+Thanks to all these people for ideas:
 
 * [Billy Cheng](https://medium.com/@billy.sf.cheng/a-rails-6-application-part-1-api-1ee5ccf7ed01) For a way to have a nice and clean implementation of the JWT on top of Devise.
 * [Daniel](https://medium.com/@tdaniel/passing-refreshed-jwts-from-rails-api-using-headers-859f1cfe88e9) For a smart way to manage token expiration.

data/app/controllers/api/v2/info_controller.rb

@@ -1,3 +1,4 @@
+require 'model_driven_api/version'
 class Api::V2::InfoController < Api::V2::ApplicationController
   # Info uses a different auth method: username and password
   skip_before_action :authenticate_request, only: [:version], raise: false

data/lib/json_web_token.rb

@@ -1,12 +1,12 @@
 class JsonWebToken
     class << self
       def encode(payload, expiry = 15.minutes.from_now.to_i)
-        JWT.encode(payload.merge(exp: expiry), Rails.application.secrets.secret_key_base)
+        ::JWT.encode(payload.merge(exp: expiry), ::Rails.application.credentials.dig(:secret_key_base))
       end
       
       def decode(token)
-        body = JWT.decode(token, Rails.application.secrets.secret_key_base)[0]
-        HashWithIndifferentAccess.new body
+        body = ::JWT.decode(token, ::Rails.application.credentials.dig(:secret_key_base))[0]
+        ::HashWithIndifferentAccess.new body
       rescue
         nil
       end

data/lib/model_driven_api.rb

@@ -1,6 +1,7 @@
 require 'thecore_backend_commons'
 require 'rack/cors'
 require 'ransack'
+require 'jwt'
 require 'json_web_token'
 require "kaminari"
 require "multi_json"

data/lib/model_driven_api/version.rb

@@ -1,3 +1,3 @@
 module ModelDrivenApi
-  VERSION = '2.2.4'
+  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.4
+  version: 2.2.9
 platform: ruby
 authors:
 - Gabriele Tassoni
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2020-05-22 00:00:00.000000000 Z
+date: 2020-10-26 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: thecore_backend_commons