Passa ai contenuti principali

Post

Visualizzazione dei post da 2021

Testare massivamente servizi Rest-API

E' facile e comodo usare Postman per testare e prototipare servizi REST/API ma come si progettano ed effettuano dei test per mettere sotto stress uno o più servizi ? Configurare una collection ad-hoc Il concetto di test massivo, quantomeno, in postman è collegato all'entità "Collection". Quindi bisogna creare una collection ad-hoc che contenga, clonandole, tutte le richieste che si vogliono testare massivamente. All'interno di questa collection vanno raccolte tutte le variabili "statiche". Queste variabili sono i parametri che NON cambiano ad ogni iterazione. Per le variabili che cambiano ad ogni iterazione useremo un file apposito. Configurare l'authorization a livello di collection Nel caso di servizi con un sistema di autenticazione bisogna configurare questo sempre a livello di collection. Una volta configurata l'autenticazione a livello di collection e magari testata isolatamente si passa all'autenticazione a livello di ogni singola requ

HAPI FHIR - HL7 Java Implementation

  Introduzione Il protocollo FHIR si sta accreditando come soluzione standard per la gestione delle risorse e la comunicazione nell'ambito del software sanitario. Qui fornisco alcuni concetti teorici di base e qualche esempio d'uso generico. HL7 HL7, Health Level 7 (HL7) è un'associazione non profit internazionale che si occupa di gestire standard per la sanità. HL7 è riferito anche ad alcuni degli specifici standard creati da questa associazione (es. FHIR v2.x, v3.0, CDA, ecc.). Fondata nel 1987 e riconosciuta dall'American National Standards Institute nel 1994, riunisce organizzazioni affiliate da oltre 40 paesi. FHIR In riferimento al protocollo, FHIR è uno standard che descrive lo scambio in forma elettronica di dati in ambiente sanitario per favorire l'interoperabilità nell'ambiente clinico di software diversi . Descrive le interfacce tra applicazioni, la definizione dei dati, dei tempi e gli errori da scambiare fra applicazioni. Il numero 7, nel nome dello

OAuth2 per autorizzare accesso a Rest/API interne ed esterne

OAuth2 per autorizzare accesso a Rest/API interne ed esterne Introduzione Quello che si vuole ottenere è l'uso dell'autenticazione OAuth2 per validare le richieste interne ad una web app a microservizi e le richieste da parte di uno o più di questi microservizi verso servizi API esterni, nello specifico l'uso della posta di Google. Il meccanismo è lo stesso che consente l'autenticazione mediante account di terzi. Validazione interna In (1) il client web "prova" ad invocare un servizio Rest/API protetto e riceve un HTTP error 400. In (2) il client web chiede un token d'accesso ad un servizio OAuth di autenticazione interno, in (3) lo riceve, in (4) usa tale token per invocare il Rest/API ed in (5) riceve la risposta con i dati. Validazione esterna Quello che ora si vuole ottenere è che una applicazione web si autentichi verso le API di Google per poter usare i servizi di questa, come ad esempio l'invio mail. Questa pratica viene detta, da Google, autent

Architetture a microservizi - concetti base

Architetture a microservizi - concetti base Introduzione Ho trattato questo argomento in maniera dettagliata per quanto riguarda la realizzazione di microservizi con JHipster in altri post che riporto nel capitolo "Approfondimenti" finale. Qui raccolgo in sintesi alcuni concetti di base. Dalla monolitica ai microservizi L'architettura a microservizi è una evoluzione adatta allo sviluppo di soluzioni software di media, grande e grandissima complessità. Rappresenta la concretizzazione dei concetti di modularità, disaccoppiamento e riusabilità tanto trattati in letteratura. Inizialmente l'architettura de-facto di tantissime soluzioni era quella rappresentata sotto come "Monolitica". La soluzione e microservizi prevede che ogni blocco logico di funzionalità sia effettivamente un "programmino"... microservizio, appunto.   I microservizi, se ben sviluppati, sono assolutamente indipendenti (funzionano anche da soli o in contesti diversi da quello iniziale

Git concetti base

Git concetti base Introduzione Git è un sistema di versionamento inventato ed implementato inizialmente da Linus Torvalds (si proprio lui, l'inventore di Linux) come alternativa a SVN. Architettura Uno schema di massima di git che ci aiuterà a capire i passaggi descritti sotto è questo: da: https://www.claudiobattaglino.it/2020/01/07/git-schema-di-funzionamento/ Uso base Git lavora a livello di filesystem (Working Directory). I comandi che seguono vanno lanciati nella specifica directory che è destinata a contenere i file del progetto da versionare, la "Working Directory". Inoltre git può lavorare sia con un repository locale che anche uno "Remote". Inizializzazione del repository $ git init Questo crea un file nascosto ".git" con la configurazione dello specifico repository. Definizione degli utenti del repository $ git config --local user.name "fchiri" Se al posto di "local" ci mettete "global" la definizione varrà per t