Quali sono i vantaggi del middleware rispetto a una classica architettura MVC per lo sviluppo di API?
I vantaggi di un'architettura middleware rispetto all'MVC sono legati proprio alla natura del middleware che meglio si presta all'erogazione di servizi basati sull'elaborazione di una risposta a partire da una richiesta HTTP. Le API web non sono altro che elaborazioni di questo tipo

Perché usare PHP, se con NodeJs ho le stesse prestazioni e un linguaggio comr javascript sicuramente più conosciuto e usato?
Anche il PHP è molto conosciuto, in passato molti team di sviluppo in PHP hanno scelto di passare a Node.js per questioni di performance. Con PHP 7 questa differenza non c'è più e quindi è possibile sviluppare API web in PHP ottenendo le stesse prestazioni di Node.js

E' possibile utilizzare Expressive per lo sviluppo di un API in un progetto PHP preesistente?
Si, Expressive si adatta bene all'integrazione con applicazioni anche legacy. La possibilità di configurare il flusso dell'applicazione e il sistema di routing rendono possibile l'integrazione verso qualsiasi applicazione PHP

Gli array rimangono dei contenitori di qualsiasi cosa oppure è possibile tipizzare i value?
Non si possono specificare i tipi degli elementi di un array in PHP 7. Esiste un workaround per gli array di oggetti, utilizzando l'operatore variadic (i tre punti ...), qui è possibile vedere un esempio d'utilizzo: https://stackoverflow.com/a/34273821

Consiglieresti di usare sempre oauth2 come sistema di autorizzazione e verifica?
Personalmente no, non credo che il sistema OAuth2 sia utile per tutte le applicazioni ma che abbia un efficacia estremamente evidente quando vogliamo aggiungere applicazioni di terze parti alla nostra infrastruttura e fare un focus molto preciso sugli scope e tutto il sistema autorizzativo.

Sono previste autorizzazioni x gruppo?
Nella specifica non viene indicato nulla ma potenzialmente la gestione degli "scope" è poi strutturata dal punto di vista applicativo e quindi è possibile muoversi per applicare scope di gruppo, come se fosse un'autorizzazione tipo: 'profile:*' con l'intento di dare un grant su tutte le risorse 'profile'.

Bisogna per forza attivare tutti i metodi di generazione del token in oauth?
Non è necessario avere tutti gli schemi di generazione del token in modo obbligatorio e possiamo scegliere in base al nostro flow di implementare solo una parte della specifica, per esempio il solo metodo "password" e "refresh token" e non implementare "auth code" e "implicit" perchè non utilizzati nella nostra piattaforma in quanto abbiamo solo client privilegiati.

Senza https quindi anche oauth2 non è considerato sicuro?
HTTPs è obbligatorio per mantenere il segreto sull'authorization token. Infatti senza HTTPs una qualunque ispezione di protocollo porterebbe alla visualizzazione del token e quindi con la perdita della sua "segretezza" automaticamente chiunque sia in possesso dello stesso potrebbe avere accesso all'infrastruttura. HTTPs è quindi NON opzionale ma obbligatorio per proteggere la connettività con gli apparati di backend.

Esempio di track log su file?
Essendo disegnato per un sistema distribuito é difficile pensare di salvare i propri dati su file, non essendo facili da ridondanti. Zipkin supporta diversi store da li si possono recuperare i dati ed eventualmente riformattarli nel formato desiderato.

Come garantire coerenza dei timestamp in maniera sana tra servizi eterogenei e distribuiti?
L'allineamento dei tempi di un sistema distribuito di solito é demandato ad applicativi come ntpd. In questo caso OpenTracing lascia libera interpretazione e non ha linee guida. Io cosiglio ntpd.

Come fare le request corrette per la paginazione? E le ricerche con filtri?
Il metodo migliore è specificare eventuali richieste di paginazione (es numero pagina, quanti contenuti restituire...) come query param o negli header di richiesta. L'importante è non renderli parte dell'url ma appunto al limite come query param.

La creazione solo di endpoint crud è sufficiente a coprire tutte le necessità di un progetto Api?
Solitamente no. Spesso si rende necessario creare endpoint che non sono lo specchio crud di una entità, ma che scatenano/si legano a specifici processi logici e di business.

Quando torna utile adottare uno sviluppo layered?
Se il nostro impianto API è discretamente complesso e e se parte della logica API potrà essere in futuro usata da altri impianti, conviene allora adottare uno sviluppo a strati.

Nomi entità : singolari o plurali?
Dipende dallo stile che si vuole adottare. Qui le migliori referenze a riguardo: http://www.restapitutorial.com/lessons/restfulresourcenaming.html

Immaginando che due pagine web accedano in get a una api rest per scaricare l' entità CUSTOMER, una però contiene solo un sottoinsieme di attributi, cosa facciamo? Due entità diverse? Usiamo deibparametri di get per specificare le "proiezioni" diverse?
L'endpoint dovrebbe restituire nella sua interezza l'entità completa. E' possibile variare l'output e forse il metodo più corretta è aggiungere un header nella richiesta che informi il server che deve restituire solo una parte della risorsa o un insieme più grande.

In una architettura REST se il client necessità di una risorsa in un determinato range temporale (filtro lato Frontend).... il client dove deve inserire questa informazione?
Sempre come query param o header di richiesta

Come migrare dei webservice al paradigma rest?
Dipende chiaramente dallo stato attuale dei webservices. IL metodo migliore è un refactoring a mano per creare un nuovo impianto API REST sencondo le reali esigenze di business. Altrimenti si possono usare anche strumenti "broker" come AWS API GATEWAY.

Quindi su Amazon si risparmia o è il tempo di attesa è comunque conteggiato come tempo di uso della macchina?
Il sistema di autoscaling fa risparmiare moltissimo sulle infrastrutture, in quanto pagando a consumo l'uso dei nodi è importante rimuovere ad aggiungere le risorse necessarie solo quando ne abbiamo effettivamente bisogno. I tempi di bootstrap dei nuovi nodi e del setup applicativo devono essere quindi ottimizzati per poter aggiungere velocemente risorse di calcolo e quindi poter usufruire subito dei nuova "energia" per fornire le risorse ai nostri utenti. L'attivazione a "gradini" del sistema autoscaling si assottiglia enormemente nei sistemi ServerLess dove si può arrivare a pagare per le sole richieste e non per la capacità di calcolo aggiunta.