architecture - tra - servizi rest json

Servizi / architettura basati su REST VC RESTFUL Servizi / Architettura

Per differenziare o confrontare questi 2, dovresti sapere cos'è REST .

REST ( RE presentational S tate T ransfer) è fondamentalmente uno stile di sviluppo architettonico con alcuni principi ...

• Dovrebbe essere apolide

• Dovrebbe accedere a tutte le risorse dal server usando solo URI

• Non ha crittografia incorporata

• Non ha sessione

• Usa uno e un solo protocollo che è HTTP

• Per eseguire operazioni CRUD, dovrebbe utilizzare verbi HTTP come get, post, put ed delete

• Dovrebbe restituire il risultato solo sotto forma di JSON o XML, atom, OData ecc. (Dati leggeri)

REST based services seguono alcuni dei principi sopra menzionati e non tutti

RESTFUL services significa che segue tutti i principi di cui sopra.

È simile al concetto di:

Object-based languages supportano tutti i concetti di OOP, esempi : C ++, C #

Object oriented languages supportano alcune delle funzionalità di OOP, esempi : JavaScript, VB

Esempio :

ASP Dot NET MVC 4 è REST-Based mentre Microsoft WEB API è RESTFul .

MVC supporta solo alcuni dei principi REST sopra menzionati, mentre le API WEB supportano tutti i principi REST di cui sopra.

MVC supporta solo quanto segue dall'API REST

• Possiamo accedere alla risorsa usando l'URI

• Supporta il verbo HTTP per accedere alla risorsa dal server

• Può restituire i risultati sotto forma di JSON, XML, ovvero HTTPResponse.

Tuttavia, allo stesso tempo in MVC

• Possiamo usare la sessione

• Possiamo renderlo stato

• Possiamo restituire il video o l'immagine dal metodo di azione del controller che sostanzialmente viola i principi REST

Questo è il motivo per cui MVC è REST-Based mentre l'API WEB supporta tutti i suddetti principi ed è RESTFul .

"REST" è un paradigma architettonico. "RESTful" descrive usando quel paradigma.

Esistono 4 livelli di API definiti nel modello di maturità di Richardson. Questi sono definiti come:

• livello 0: qualsiasi sistema che abbia un singolo endpoint per tutte le sue apis (SOAP o RPC rientrano in questa categoria). Le apis di livello 0 possono anche somigliare ai "comandi".

• livello 1: un sistema descritto da ResourceUri. Questo è un sistema che definisce più URI basati sull'entità (invece di avere un singolo endpoint come farebbe un sistema di livello 0). Questi URI possono utilizzare diverse azioni http (POST, GET, PUT, ecc.) Per implementare diverse azioni contro quella risorsa.

• livello 2: alias livello 1 w / un uso conforme di metodi standard HTTP / verbi e risposte multi codice di stato

• livello 3: alias livello 2 più HATEOAS (hypermedia incluso nella risposta che descrive le chiamate aggiuntive che puoi effettuare)

Mentre i livelli 1, livello 2 e livello 3 possono essere considerati come sistemi REST, solo i livelli più severi (noti anche come livello 2 e livello 3) sono considerati come RESTful.

Quindi sostanzialmente tutti gli apis RESTful sono apis REST, ma non tutti gli apis REST sono RESTful

definizione del modello di maturità di Richardson

I servizi Web sono essenzialmente siti Web il cui contenuto viene utilizzato da programmi per computer, non da persone. REST è un insieme di principi architetturali che stabiliscono che i servizi Web dovrebbero sfruttare al massimo HTTP e altri standard Web, in modo che i programmi ottengano tutto il materiale che le persone possono già ottenere dal Web. REST è spesso in contrasto con i servizi Web SOAP e altri servizi Web "remote procedure call".

Le presentazioni di Stefan Tilkov su REST su Parleys.com sono abbastanza buone, specialmente questa .

Per un libro, non si può ottenere niente di meglio di Restful Web Services di Richardson e Ruby.

REST sta per trasferimento di stato rappresentazionale. Ciò significa che lo stato stesso non viene trasferito, ma una semplice rappresentazione di esso è. L'esempio più comune è un'app basata esclusivamente su server HTML (non javascript). Il browser non sa nulla dell'applicazione stessa ma attraverso collegamenti e risorse, il server è in grado di trasferire lo stato dell'applicazione al browser. Dove normalmente un pulsante cambia una variabile di stato (ad esempio la pagina aperta) in una normale applicazione di Windows, nel browser è presente un collegamento che rappresenta tale cambiamento di stato.

L'idea è di usare hypermedia. E forse per creare nuovi tipi di ipermedia. Potenzialmente possiamo espandere il browser con javascript / AJAX e creare nuovi tipi di ipermedia personalizzati. E avremmo una vera applicazione REST.

Questa è la mia versione breve di ciò che REST rappresenta, il problema è che è difficile da implementare. Dico personalmente RESTful, quando voglio fare riferimento ai principi REST, ma so che non sto davvero implementando l'intero concetto di REST. Non lo diciamo in realtà, perché si utilizza SOAP o no. Penso che la maggior parte delle persone non faccia REST come è stato immaginato dal suo creatore Roy Fielding, in realtà implementiamo architetture RESTful o RESTlike. Puoi vedere la sua dissertation e troverai l'acronimo REST ma non la parola RESTful.

Representational State Transfer (REST) ​​è uno stile di architettura software per sistemi ipermediali distribuiti come il World Wide Web. Il termine Representational State Transfer è stato introdotto e definito nel 2000 da Roy Fielding 1 [2] nella sua tesi di dottorato. Fielding è uno dei principali autori delle specifiche della specifica HTTP (Hypertext Transfer Protocol) 1.0 e 1.1. La conformità ai vincoli REST viene definita "RESTful". 1

Un servizio basato su REST è chiamato "servizio RESTful".

Sorgo di fare affidamento sul post che: Dr.Dobbs Archive

grazie per le risposte Leggi http://www.ibm.com/developerworks/webservices/library/ws-restful/ di Alex Rodriguez che suggerisce che un servizio web RESTful ha 4 caratteristiche di base che sono:

1. Utilizzare i metodi HTTP in modo esplicito.
2. Essere apolidi.
3. Esporre gli URI di struttura di directory.
4. Trasferisci XML, JavaScript Object Notation (JSON) o entrambi.