Verifica su Web Services

1. Descrivere cosa si intende quando si parla di web services e fare descrizione delle tipologie di web services che abbiamo visto, SOAP e REST, evidenziandone inoltre le differenze.

2. Dato un servizio blog con interfaccia di gestione di tipo REST per permettere di gestire utenti, posts (articoli) e commenti ai post, con queste URI:

OPERAZIONE	URL	Descrizione
Gestione utenti	/users
Gestione dei post	/posts
	/posts?userId={:userId}	per vedere i post di un certo utente (ricerca) in base a id utente
Gestione dei commenti	/posts/{:postId}/comments	postId è un intero che rappresenta in modo univoco il post

*Gli utenti, i post e i commenti avranno ognuno un proprio id identificativo.

Da fare:

• Scrivere una chiamata REST e response del server:

  • per visualizzare tutti gli utenti;

  • cancellare un utente specifico;

  • modificare i dati di un utente;

• Chiamata al web service con response per inserire un nuovo post;

• Chiamata al web service con response per inserire un nuovo commento ad un post;

Stabilite voi i campi che ritenete più opportuni per gli utenti, posts e commenti del blog.

DISCUSSIONE

Fanno parte della problematica della programmazione distribuita. I web service sono un modo pragmatico di integrare sistemi e di riutilizzare una business logic comune.

Il modo più di basso livello che abbiamo visto, per fare programmazione distribuita, è tramite le socket, TCP o UDP, in cui client e server stabiliscono una connessione e un protocollo (una convenzione) per comunicare.

Comunicazione su socket TCP client/server

Accennato anche alla tecnologia di Remote Procedure Call, che astraggono dalle socket per fare la programmazione distribuita, e simulano la chiamata di funzione: da un oggetto in un processo potete chiamare un metodo di un altro oggetto in un altro processo, sullo stesso host ma generalmente su host differenti. La tecnologia più famosa è CORBA (che permette di far comunicare applicazioni scritte anche in linguaggi differenti) mentre in ambito Java, RMI (Remore Method Invocation).

Remote procedure call

Questo in genere porta a delle problematiche di sicurezza perché a basso livello la comunicazione avviene su porte non standard e quindi c'è l'esigenza di lasciare aperte porte sul firewall aumentando così i problemi di sicurezza.

Il termine web service riferisce a una funzione software che può essere chiamata tramite HTTP, come mezzo di trasporto su cui i dati sono portati (ad esempio servizi SOAP/WSDL) o utilizzando HTTP come un application protocol che definisce la semantica per il comportamento dei web service (es i RESTFul services).

Sotto una tabella con i termini comunemente usati nei web services come sinonimi: nella prima colonna, i nomi per indicare i processi software che inviano richieste o generano eventi. Nella seconda colonna i nomi per le funzioni software che rispondono a queste richieste o eventi.

Client	Service
Requestor	Provider
Service consumer	Service provider

I termini client e service sono comuni ai servizi SOAP/WSDL che RESTFul.

SOAP/WSDL

E' un protocollo standard in formato XML che utilizza generalmente HTTP come protocollo di trasporto.

Il WSDL, Web Service Definition Language, è un linguaggio in formato XML per descrivere l'interfaccia, le funzionalità, del web service.

Il formato messaggio SOAP come è composto:

Formato SOAP Message

RESTFul

Non è uno standard, è un'architettura che deve soddisfare questi requisiti:

• Client/Server:

• Serverless:

• Cachable responses:

• Uniform Interface:

• Layered system:

Sotto la proposta per l'interfaccia REST al servizio di un blog.

Visualizzazione utenti

Task	Metodo	PATH
Visualizzazione utenti	GET	/users

Response

Codice 200 OK nell'header e body response, es:

[    
   {
        "id": 1,
        "name": "Massimo",
        "email": "[e-mail]"
    },
    {
        "id": 2,
        "name": "Luca",
        "email": "[e-mail]"
    }
]

Cancellazione utente

Task	Metodo	Path
Cancellazione utente (in questo caso utente con id = 1)	DELETE	/users/1

Response

Codice 200 OK nell'header e body vuoto (quest'ultima scelta implementativa, magari invece si può decidere di tornare la rappresentazione dell'entità cancellata)

Modifica utente

Task	Method	Path	Body
Modifica dati utente (in questo caso utente con id = 2)	PUT	/users/2	{ "id": 2, "name": "Luca", "email": "[e-mail]" }

Response

Codice 200 OK nell'header e body:

{
    "id": 2,
    "name": "Luca",
    "email": "[e-mail]"
}

Oppure sempre per modificare dati entità utente, utilizzando il metodo PATCH:

Task	Metodo	Path	Body
Modifica dati utente (in questo caso utente con id = 2)	PATCH	/users/2	{ "email": "[e-mail]" }

Response

Identica all'utilizzo di PUT, codice 200 OK nell'header e body:

{
    "id": 2,
    "name": "Luca",
    "email": "[e-mail]"
}

Inserimento nuovo post (articolo)

Ammettiamo che ci siano già 3 post e ne vogliamo aggiungere un 4 legato all'utente 1.

Task	Metodo	Path	Body
Aggiungi un post all'utente 1	POST	/posts	{ "title": "Tom e Jerry", "userId": 1 }

Response

Codice 201 Created nell'header e body:

{
  "title": "Tom e Jerry",
  "userId": 1,
  "id": 4
}

Inserimento di nuovo commento a un post

Ammettiamo di voler aggiungere un nuovo commento al primo post (ha già due commenti)

Task	Metodo	Path	Body
Aggiungo un commento al post con id = 1	POST	/posts/1/comments	{ "body": "Terribile!" }

Response

Codice 201 Created nell'header e body:

{
  "body": "Terribile!!!",
  "postId": "1",
  "id": 3
}