Guida al Linguaggio PHP. Lezione 19. L’Architettura REST API
Classifica Articoli e Pagine
Privacy e cookie: Questo sito utilizza cookie. Continuando a utilizzare questo sito web, si accetta l’utilizzo dei cookie.
Per ulteriori informazioni, anche su controllo dei cookie, leggi qui: Informativa sui cookie
Per ulteriori informazioni, anche su controllo dei cookie, leggi qui: Informativa sui cookie
Analisi SEO
Geo IP Site
Htaccess
- Redirec Nuova Directory vecchia directory
- Redirect Vecchio Url nuovo url
- Redirect Nuovo Dominio Vecchio Dominio
Tipi di articoli
Categorie
Categorie
Tag
Anno
Guida al linguaggi di programmazione PHP
La nostra Guida al linguaggio di programmazione PHP
Lezione 1 Guida introduttiva al linguaggio PHP
Lezione 2 Introduzione ai tipi di dato PHP
Lezione 3. I Cicli Iterativi
Lezione 4. Le funzioni
Lezione 5 Gli Array
Lezione 6. La programmazione a Oggetti
Lezione 7. La programmazione a Oggetti Parte 2
Lezione 8. Il Database Mysql
Lezione 9. Interazione con HTML
Lezione 10 I Cookie Session
Lezione 11 Composer Gestore delle Dipendenze
Lezione 12 Parser Feed XML
Lezione 13. Esistenza Url
Lezione 14. Esistenza Dominio
Lezione 15. Invio Email
Lezione 16. I Namespace
Lezione 17. I Traits
Lezione 18. La Cache
Lezione 19. Architetuttra Rest Api
Lezione 20. Soap WSDL
Lezione 20 BIS. SOAP WSDL ZEND Framework
Lezioni 21. Cloud Computing
Lezioni 22. Sicurezza
Lezione 23. Codice di errore Offset comuni
Composer
Guida installazione e utilizzo dell'applicazione per le dipendenze delle librerie Composer.
Che cos'è Composer
Installazione
Caricare le Librerie
Aggiornare le Librerie
Tipi di articoli
Categorie
Categorie
Tag
Anno
L | M | M | G | V | S | D |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
Legge sui Cookies
Utilizziamo i cookie sul nostro sito Web per offrirti l'esperienza più pertinente ricordando le tue preferenze e ripetendo le visite. Cliccando su "Accetta" acconsenti all'uso di TUTTI i cookie. Puoi visionare la nostra politica sui Cookie alla Pagina sulla Cookie Policy . Nella pagina potrai trovare tutti i cookie che il sito utilizza e il trattamento che viene effettuato sui cookie stessi , sul sito dove vengono immagazzinati e sul trattamento a cui sono sottoposti.Per ogni dubbio o approfondimento ti invitiamo a contattarci grazie al nostro modulo di contatto
Privacy & Cookies Policy
Privacy
Questo sito Web utilizza i cookie per migliorare la tua esperienza durante la navigazione nel sito Web. Di questi cookie, i cookie classificati come necessari vengono memorizzati nel browser in quanto sono essenziali per il funzionamento delle funzionalità di base del sito Web. Utilizziamo anche cookie di terze parti che ci aiutano ad analizzare e capire come utilizzi questo sito web. Questi cookie verranno memorizzati nel tuo browser solo con il tuo consenso. Hai anche la possibilità di disattivare questi cookie. Ma la disattivazione di alcuni di questi cookie potrebbe avere un effetto sulla tua esperienza di navigazione.
I cookie necessari sono assolutamente essenziali per il corretto funzionamento del sito web. Questa categoria include solo i cookie che garantiscono funzionalità di base e caratteristiche di sicurezza del sito web. Questi cookie non memorizzano alcuna informazione personale.
Tutti i cookie che potrebbero non essere particolarmente necessari per il funzionamento del sito Web e vengono utilizzati specificamente per raccogliere dati personali dell\'utente tramite analisi, pubblicità, altri contenuti incorporati sono definiti come cookie non necessari. È obbligatorio ottenere il consenso dell\'utente prima di eseguire questi cookie sul tuo sito web.
%d blogger hanno fatto clic su Mi Piace per questo:
Ci occupiamo adesso dei Web Services. In primis che cosa sono e le loro differenze. Diciamo che sono dei servizi in grado di fare comunicare fra di loro strutture hardware e software differenti. Per esempio un ‘applicazione scritta in JAVA su Sistema Operativo Linux sarà in grado di comunicare con un’applicazione PHP su SO PHP.
Artchitettutura REST
E’ l’acronimo di REpresentational State Transfer e fu introdotto da Roy Fielding nel 2000 come tesi di dottorato. Con questo termine si intente ogni interfaccia che trasmetta dati attraverso protocollo HTTP senza livelli opzionali ( come nel SOAP) o cookie, ma con dei vincoli che vi andiamo ad elencare
Il sistema deve interagire su una piattaforma client server. Ossia dove il client comunichi su una setta piattaforma del server e quindi non abbiano problemi di comunicazione.
Statelessness
La comunicazione client-server è limitata dal fatto che nessun client venga memorizzato sul server tra le richieste. Ogni richiesta da qualsiasi client deve contenere tutte le informazioni necessarie per soddisfare la richiesta e lo stato della sessione viene mantenuto nel client. Lo stato della sessione può essere trasferito dal server a un altro servizio come un database per mantenere uno stato permanente per un periodo e consentire l’autenticazione. Vedi l’architettura API 2.0. Il client inizia a inviare richieste quando è pronto per passare a un nuovo stato. Mentre una o più richieste sono in sospeso, il client è considerato in transizione .
Cacheability
Riprende il concetto già introdotto nel WWW dove i client e altri intermediari possono memorizzare le risposte nella cache. Le risposte del server possono pertanto provenire dalla cache e non impedire ai client di riutilizzare dati obsoleti o inappropriati in risposta a ulteriori richieste. Il caching ben gestito elimina parzialmente o completamente alcune interazioni client-server, migliorando ulteriormente la scalabilità e le prestazioni.
Stratificazione multi-tiered
Un cliente non può di norma dire se è collegato direttamente al server finale o ad un intermediario . I server intermedi dunque possono migliorare la scalabilità del sistema abilitando il bilanciamento del carico e fornendo cache condivise. Possono anche applicare al fine di instituire politiche di sicurezza..
Accesso uniforme
I sistemi distribuiti devono essere accessibili in maniera uniforme: ossia ogni risorsa deve avere un indirizzo univoco globale e un punto valido di accesso.
Codice a Richiesta. (opzionale)
I server possono temporaneamente estendere le funzionalità del client trasferendo del codice eseguibile. Come Applet Java o linguaggi di scripting client side come JavaScript. “Code on demand” è l’unico vincolo opzionale.
I Web Services comunicano attraverso le API dei servizi Web che aderiscono ai vincoli architetturali REST e per questo sono chiamate API RESTful. Sono basate su HTTP sono definite con i seguenti requisiti
URL di base ad esempio http://api.example.com/resources
un tipo di supporto Internet che definisce gli elementi di dati di transizione di stato (ad esempio, Atom, microformati, application / vnd.collection + json, ) La rappresentazione corrente indica al client come comporre le richieste di transizione a tutti i prossimi stati di applicazione disponibili. Questo potrebbe essere semplice come un URL o complesso come un applet Java.
metodi HTTP standard (ad es. OPTIONS, GET, PUT, POST e DELETE)
Le API accedono o interrogano una risorsa. Ora rimane da comprendere che cosa si nasconda dietro il termine di risorsa. Che effettivamente è abbastanza astratto. Intanto la definizione precisa è Web Resources proprio ad indicare che alla stessa si accede attraverso il web.
Diciamo che una Web Resource è una qualsiasi servizo messo a disposizione del server tramite il quale interagire tramite le API. Gli utenti tramite le API interrogano la risorsa al fine di ricevere un servizio.
Ma quali sono i modi con cui le risorse vengono interrogati?
Sono i metodi che abbiamo già incontrato sopra ossia GET, PUT, POST e DELETE. Vediamo di chiarire con un esempio
Supponiamo di dovere interrogare una determinata risorsa in remoto del tipo
http://api.nome_sito_web.com/risorsa/
In questo caso il metodo
E dal modo generico in cui vi ho descritto il tutto si comprende meglio la differenza fra SOAP e REST. Ossia il SOAP è un protocollo e quindi deve obbedire a delle strutture fisse. Il REST è un ‘architetutta e come tale ha un certo grado di libertà nell’essere implementata.
Condividi:
Mi piace: