Anteprima
Vedrai una selezione di 7 pagine su 29
Realizzazione Web Services attraverso Spring Boot Pag. 1 Realizzazione Web Services attraverso Spring Boot Pag. 2
Anteprima di 7 pagg. su 29.
Scarica il documento per vederlo tutto.
Realizzazione Web Services attraverso Spring Boot Pag. 6
Anteprima di 7 pagg. su 29.
Scarica il documento per vederlo tutto.
Realizzazione Web Services attraverso Spring Boot Pag. 11
Anteprima di 7 pagg. su 29.
Scarica il documento per vederlo tutto.
Realizzazione Web Services attraverso Spring Boot Pag. 16
Anteprima di 7 pagg. su 29.
Scarica il documento per vederlo tutto.
Realizzazione Web Services attraverso Spring Boot Pag. 21
Anteprima di 7 pagg. su 29.
Scarica il documento per vederlo tutto.
Realizzazione Web Services attraverso Spring Boot Pag. 26
1 su 29
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

Formattazione del testo

Queste due tabelle verranno mappate attraverso due classi: Categoria.java e Veicolo.java. Ognuno dei quali avrà la stessa struttura della classe mostrata come esempio in precedenza.

La tabella con cardinalità N avrà, nel rispettivo file Java, la seguente notazione:

@ManyToOne
@JoinColumn(name='x', referencedColumnName='y')
@JsonBackReference(value='id_relazione')
@EqualsAndHashCode.Exclude

Dove x indica il nome della colonna relativa alla Foreign key (categoria_pk), mentre y indica il nome della colonna relativa alla chiave primaria della tabella con cardinalità 1 (id_categoria).

La tabella con cardinalità 1 avrà, nel rispettivo file Java, la seguente notazione:

@OneToMany(mappedBy='x', cascade=cascadeType.All, orphanRemove=true)
@JsonManagedReference(value='id_relazione')

Dove x indica il nome dell'attributo utilizzato per esprimere l'entità @ManyToOne nella classe.

classe Employee.java.classe che mappa la tabella employe (employe.java). 11NBSe per scopi progettuali la terza tabella deve contenere altri attributi oltre alle due chiavi esterne, occorre mapparle con la relazione una a molti studiata in precedenza. 4 - REPOSITORY PACKAGE In questo package specifico devono essere inserite tutte quelle classi (in questo caso interfacce) che eseguono le operazioni CRUD sul database relazionale. Per rispettare lo standard JPA occorre inserire la seguente sintassi in ogni interfaccia creata: Di seguito riportiamo un esempio per ogni tipologia. SELECT L'annotazione @Query definisce l'operazione che la funzione sotto indicata deve svolgere. DELETE UPDATE parametri INSERT parametri valori 5 - SERVICES PACKAGE In questo package vengono inserite tutte le interfacce che definiscono il layer di servizio di una web application. Si ricorda che questo layer deve contenere tutta la logica di business dell'applicazione. Ogni interfaccia creata deve avere la sua classe di Prendiamo come esempio l'interfaccia utenteServices. La relativa classe di implementazione sarà: L'annotazione inserita all'inizio della classe indica @Transactional(readOnly=true), transizioni di sola lettura (vale per le query di selezione). Mentre per le query di inserimento, modifica ed eliminazione occorre inserire sopra il metodo @Transactional. Nel package CONTROLLER vengono inserite tutte le API del web services. Indipendentemente dal tipo di richiesta che si vuole implementare, ogni volta che viene definita una classe controller occorre inserire le seguenti notazioni: @RestController @RequestMapping("/path") Con la prima indichiamo che si tratta di un controller di tipo REST mentre con la seconda definiamo l'URL di base. La sintassi da seguire per una richiesta GET (select) è la seguente: @GetMapping(value= @RequestMapping(value = "/path/{par}", produces = "application/json") public ResponseEntity<Object> nome-metodo (@PathVariable("par") String val ){ // Corpo funzione // Eventuale gestioni delle eccezioni return new ResponseEntity<Object> (dati, HttpStatus.OK); }

La sintassi {par} non è obbligatoria.

Prima di analizzando gli altri metodi, vediamo come si gestiscono eventuali errori all'interno delle classi controller.

6.2 - Gestione eccezioni

Iniziamo l'analisi creando un nuovo package chiamato exception all'interno dell'applicazione.

Ogni tipo di eccezione deve essere gestito all'interno di una classe presente nel package creato (il programmatore decide quali errori gestire).

Supponiamo di voler gestire l'eccezione NotFoundException, si attiva ogni volta che si applica un filtro ad una lista dati senza ottenere risultati.

Creiamo la relativa calasse all'interno del package creato in precedenza.

metodo all'interno di una specifica classe che converta il messaggio in formato JSON. In questa classe è possibile definire tutti i metodi relativi alla conversione di ogni eccezione. Chiameremo quest'ultima RestExceptionHandler. Di seguito riportiamo la sintassi relativa Conversione messaggio del metodo NotFoundException. Dove nella classe ErrorResponse viene definita la formattazione dell'errore. Per attivare l'eccezione nell'EndPoint di interesse, occorre inserire la seguente EndPoint sintassi.

186.3 - Validazione dati

Prima di inserire e modificare i dati all'interno del database, è buona regola validare e controllare i dati inseriti dall'utente. Questa validazione può essere effettuata sia lato FrontEnd che lato WebServices. Per implementare tale sistema (lato BackEnd) bisogna innanzitutto inserire la classe MessageConfig nel package principale dell'applicazione. In base alle configurazioni effettuate, i messaggi da visualizzare.

In caso divincolo non rispettato, vengono estratti dal file messages_it.properties presente nella cartella src/main/resources.

Attraverso opportune annotazioni messe a disposizione da Hibernate-Validation è possibile verificare se un specifico attributo (dato inserito dall'utente) rispetti un insieme di vincoli. Questi devono essere applicati sugli attributi delle classi di entity.

Di seguito riportiamo le annotazioni messe a disposizione da Hibernate:

Esempio:

Dove con la keyword message indichiamo l'identificativo del messaggio da visualizzare nel momento in cui vengono violati i vincoli. La specifica del messaggio si trova nel file citato in precedenza.

Per attivare e controllare i vincoli specificati, occorre inserire come parametro nei metodi delle classi controller (definiscono gli EndPoint) la notazione @Valid, e nel corpo della funzione uno specifico controllo:

@Autowired private ResourceBundleMessageSource errMessage;

public ResponseEntity<Object> nome-funzione (@Valid,

(insert/update)La sintassi da seguire per una richiesta put è la seguente: @PutMapping(value= "/path/{id}", produces="application/json") public ResponseEntity nome-metodo (@PathVariable("id") Long id, @Valid @RequestBody Object val, BindingResult result) { //Controllo vincoli //Controllo esistenza dato da aggiornare //Aggiornamento dato ObjectMapper mapper = new ObjectMapper(); ObjectNode responseNode = mapper.createObjectNode(); responseNode.put("code", HttpStatus.OK.toString()); responseNode.put("message", "aggiornamento effettuato"); return new ResponseEntity<>(responseNode, new HttpHeaders(), HttpStatus.OK); } Con la notazione @PathVariable("id") indichiamo che il parametro "id" viene preso dall'URL della richiesta.produce = "application/json")public ResponseEntity nome-metodo (@PathVariable("id") Long id) {//Controllo esistenza dato da eliminare//Eliminazione datoObjectMapper mapper = new ObjectMapper();ObjectNode responseNode = mapper.createObjectNode();responseNode.put("code", HttpStatus.OK.toString());responseNode.put("message", "eliminazione effettuata");return new ResponseEntity<>(responseNode, new HttpHeaders(), HttpStatus.OK);}Con la notazione @PathVariable indichiamo che il parametro si trova nell'URL della richiesta effettuata dal Front-End.produce="application/json")public ResponseEntity nome-metodo (@PathVariable("id") String val ){ //Controllo esistenza dato //Eliminazione dato 22 ObjectMapper mapper = new ObjectMapper(); ObjectNode responseNode = mapper.createObjectNode(); responseNode.put("code", HttpStatus.OK.toString()); responseNode.put("message", "eliminazione effettuata"); return new ResponseEntity<>(responseNode, new HttpHeaders(), HttpStatus.OK); } 7 - SICUREZZA BASATA SUL JWT Dal punto di vista teorico, lo standard Json Web Token (RFC 7519) permette di: - Trasferire i dati in maniera sicura - Le informazioni vengono memorizzate all'interno di una stringa alfanumerica - Permette di effettuare l'autenticazione - Permette di stabilire il ruolo e il tempo di autenticazione Il token in questione viene generato da un servizio specifico che occorre implementare all'interno del nostro Web Services. Una volta ottenuto il tokenÈ possibile richiamare le diverse API presenti nellanostra applicazione. In caso contrario si ottiene un messaggio di errore come risposta alla richiesta effettuata. Analizziamo come implementare il servizio JWT nella nostra applicazione. Iniziamo inserendo le seguenti dipendenze nel file pom.xml Successivamente occorre creare nel progetto un package dove inserire tutte le classi relative alle varie configurazioni di sicurezza. Chiameremo il package security. All'interno del package creato, inseriamo le classi seguenti: 7.1 - Configurazione CORS Con la prima configurazione evidenziata indichiamo che tutte le ap
Dettagli
Publisher
A.A. 2019-2020
29 pagine
SSD Scienze matematiche e informatiche INF/01 Informatica

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher gnmmrr di informazioni apprese con la frequenza delle lezioni di progettazione e programmazione web e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Milano - Bicocca o del prof Mariani Leonardo.