Visualizzazione dei risultati da 1 a 6 su 6
  1. #1
    Utente di HTML.it
    Registrato dal
    Mar 2019
    Messaggi
    16

    Comunicazione tra Rest WebServices

    Ciao a tutti,
    sto lavorando ad un progetto composto da servizi Rest tramite l'ausilio del framework Jersey.
    I vari servizi funzionando perfettamente se testati uno ad uno in modo indipendente ma qui sorge il mio problema.

    come faccio a far comunicare tra loro dei servizi rest?

    faccio un esempio:
    Servizio A: mi prende in dati dal FrontEnd (idAccount, Nome, Cognome etc...) e li mette in formato JSON
    servizio B: prende alcuni dati dal servizio A e fa dei controlli sul DB.

    come faccio ad inviare tali dati dal servizio A al servizio B?

    Grazie

  2. #2
    Quote Originariamente inviata da acronalb Visualizza il messaggio
    Ciao a tutti,
    come faccio ad inviare tali dati dal servizio A al servizio B?
    Devi usare una API/libreria di "HTTP client" per fare delle request verso altri servizi. E visto che hai parlato di REST, sarebbe utile una API/libreria che permetta di ragionare meglio in termini di REST.

    Non so che versione di Jersey usi ma se implementa JAX-RS 2.x (e non la 1.x), allora sappi che in JAX-RS 2 c' gi una client API standard.

    Poi dove/come tenere gli url (se cablarli nel codice o renderli configurabili ecc...) un altro discorso.
    Andrea Senior Java developer SCJP 5 (91%) SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

  3. #3
    Utente di HTML.it
    Registrato dal
    Mar 2019
    Messaggi
    16
    Quote Originariamente inviata da andbin Visualizza il messaggio
    Devi usare una API/libreria di "HTTP client" per fare delle request verso altri servizi. E visto che hai parlato di REST, sarebbe utile una API/libreria che permetta di ragionare meglio in termini di REST.

    Non so che versione di Jersey usi ma se implementa JAX-RS 2.x (e non la 1.x), allora sappi che in JAX-RS 2 c' gi una client API standard.

    Poi dove/come tenere gli url (se cablarli nel codice o renderli configurabili ecc...) un altro discorso.
    da poco che mi sono messo a studiare i Rest Service, sapresti indicarmi qualche esempio su libri o siti? ho provato a cercare esempi concreti ma non ho trovato quasi nulla.

    al momento quello che faccio questo :

    codice:
    System.out.println(StringInJson.stringFromJson(gson.toJson(WalletAdaptor.fromGiocataToWallet(g1)).toString()));        
            String stringToSend = StringInJson.stringFromJson(gson.toJson(WalletAdaptor.fromGiocataToWallet(g1)).toString());
            
            String url = "http://localhost:8080/orches/webapi/wallet/saldo/"+stringToSend; 
             // create request.
             HttpClient client = HttpClientBuilder.create().build(); 
             HttpGet request = new HttpGet(url); 
             // execute your request. 
             HttpResponse response = client.execute(request); 
            
             HttpEntity entity = response.getEntity();
             // Read the contents of an entity and return it as a String.
             String content = EntityUtils.toString(entity);
             System.out.println(content);
    in pratica all'url che chiama l'altro servizio Rest ci ho aggiunto in coda un parametro stringa che contiene tutto il JSON dei dati che voglio inviargli.
    la classe StringInJson rimpiazza i caratteri "illegali" che non potrei inviare con l'url (es parentesi graffe e virgolette).

    corretto o si fa in un altro modo ?

    la versione di jersey che sto utilizzando al momento la 2.27

  4. #4
    Quote Originariamente inviata da acronalb Visualizza il messaggio
    da poco che mi sono messo a studiare i Rest Service, sapresti indicarmi
    codice:
    System.out.println(StringInJson.stringFromJson(gson.toJson(WalletAdaptor.fromGiocataToWallet(g1)).toString()));        
            String stringToSend = StringInJson.stringFromJson(gson.toJson(WalletAdaptor.fromGiocataToWallet(g1)).toString());
            
            String url = "http://localhost:8080/orches/webapi/wallet/saldo/"+stringToSend;
    corretto o si fa in un altro modo ?
    No, non proprio un buon modo. A parte che per encodare dei dati da usare nel url ci sono gi funzionalit apposite es. la java.net.URLEncoder del framework standard.

    Ma la questione comunque pi "profonda". Perch mai dovresti mettere un pezzo di JSON dentro un url?? Non si fa ....

    E quel /orches/webapi/wallet/saldo/ concettualmente cosa fa? Un insert o update?? E se s, allora perch lo fa con metodo GET?

    Il punto che penso (temo ....) che in quello che hai fatto, di REST ci sia poco/nulla. REST non vuol dire "ah, faccio tutti gli endpoint che voglio, mettendo quello che mi pare nel url e usando i verbi HTTP come capita". No, questo non REST ... HTTP usato a cavolo ...
    Andrea Senior Java developer SCJP 5 (91%) SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

  5. #5
    Utente di HTML.it
    Registrato dal
    Mar 2019
    Messaggi
    16
    Quote Originariamente inviata da andbin Visualizza il messaggio
    Ma la questione comunque pi "profonda". Perch mai dovresti mettere un pezzo di JSON dentro un url?? Non si fa ....
    proprio questo il mio dubbio, non mi sembrava molto bello aggiungere un JSON in un url ma l'unico modo che ho trovato "funzionante".

    Faccio un esempio riguardo quello che non ho capito.
    Leggendo su vari siti e guide, creare un progetto basato su microservizi Rest consiste nel creare dei microservizi ognuno per ogni azione "basilare".
    Partendo da questa frase per effettuare una semplice chiamata al DB mi viene da pensare cos
    - creo un servizio Rest (lo chiamo A) che mi legge i dati dal Client (es l'idAccount) .
    - creo un servizio Rest (lo chiamo B) che mi interroga il DB con l'idAccount per vedere il saldo nel wallet.

    Fin qui la struttura pi o meno corretta?
    ora quello che mi manca come faccio ad inviare il mio idAccount dal servizio A al B con cui poi va a fare l'interrogazione al DB?

    Ovviamente un esempio semplice, giusto per capire un concetto a me non molto chiaro, ma il servizio A comprende altre operazioni che richiama in base ai dati che riceve dal client.

  6. #6
    Quote Originariamente inviata da acronalb Visualizza il messaggio
    proprio questo il mio dubbio, non mi sembrava molto bello aggiungere un JSON in un url ma l'unico modo che ho trovato "funzionante".
    Non questione se "funziona" ... NON REST.

    Quote Originariamente inviata da acronalb Visualizza il messaggio
    consiste nel creare dei microservizi ognuno per ogni azione "basilare".
    S ma non c'entra nulla direttamente con REST. Poi non che deve fare solo una cosa, pu anche fare pi cose purch molto correlate. Se un microservizio si occupa di gestire gli utenti (elencarli, registrarli, ecc..) allora non si occuper di certo di ricevere gli ordini di prodotti, perch un contesto ben diverso.

    Quote Originariamente inviata da acronalb Visualizza il messaggio
    Fin qui la struttura pi o meno corretta?
    ora quello che mi manca come faccio ad inviare il mio idAccount dal servizio A al B con cui poi va a fare l'interrogazione al DB?
    Non questo il punto. La vera questione REST, che temo non hai affatto usato.

    REST innanzitutto uno "stile architetturale". L'obiettivo generale di utilizzare HTTP come protocollo di livello "applicativo", sfruttando tutto ci che HTTP ha da offrire, cio: url, header, verbi, status code, content-negotiation, ecc...

    REST vuol dire Representational State Transfer, il concetto essenziale quello di trasferire avanti e indietro delle "rappresentazioni" delle risorse. Che possono essere in vari formati, JSON, XML, altro. Se l'applicazione fatta e gestita opportunamente, pu anche offrire pi formati per una stessa risorsa in base alla content-negotiation tra client e server. Un client A potrebbe chiedere la rappresentazione XML di un libro con ID 1234 e un altro client B potrebbe chiedere la rappresentazione JSON dello stesso libro con ID 1234.


    A livello basilare vuol dire:
    - sfruttare gli url per rappresentare delle "risorse"
    - usare i verbi HTTP (es. GET, POST ecc...) per realizzare le classiche operazioni CRUD (create-read-update-delete)


    Esempio semplice: gestione di libri. Si stabilire un url che rappresenta la "collezione" dei libri es.
    http://blabla/api/books
    (nota, books al plurale!)


    GET http://blabla/api/books
    per ottenere la lista dei libri (eventualmente filtrata e/o paginata e/o ordinata usando appositi query param)

    GET http://blabla/api/books/1234
    per ottenere la rappresentazione del libro di ID 1234

    POST http://blabla/api/books
    per inserire un nuovo libro (rappresentazione del libro nel body della request)

    PUT http://blabla/api/books/1234
    per aggiornare il libro di ID 1234 (nuova rappresentazione del libro nel body della request)

    DELETE http://blabla/api/books/1234
    per eliminare il libro di ID 1234


    Se hai fatto qualcosa gi di abbastanza/molto diverso da una cosa del genere .... non REST ..... HTTP usato a casaccio ...
    Andrea Senior Java developer SCJP 5 (91%) SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

  7. #7
    Utente di HTML.it
    Registrato dal
    Mar 2019
    Messaggi
    16
    Quote Originariamente inviata da andbin Visualizza il messaggio
    Non � questione se "funziona" ... NON � REST.


    S� ma non c'entra nulla direttamente con REST. Poi non � che deve fare solo una cosa, pu� anche fare pi� cose purch� molto correlate. Se un microservizio si occupa di gestire gli utenti (elencarli, registrarli, ecc..) allora non si occuper� di certo di ricevere gli ordini di prodotti, perch� � un contesto ben diverso.


    Non � questo il punto. La vera questione � REST, che temo non hai affatto usato.

    REST innanzitutto � uno "stile architetturale". L'obiettivo generale � di utilizzare HTTP come protocollo di livello "applicativo", sfruttando tutto ci� che HTTP ha da offrire, cio�: url, header, verbi, status code, content-negotiation, ecc...

    REST vuol dire Representational State Transfer, il concetto essenziale � quello di trasferire avanti e indietro delle "rappresentazioni" delle risorse. Che possono essere in vari formati, JSON, XML, altro. Se l'applicazione � fatta e gestita opportunamente, pu� anche offrire pi� formati per una stessa risorsa in base alla content-negotiation tra client e server. Un client A potrebbe chiedere la rappresentazione XML di un libro con ID 1234 e un altro client B potrebbe chiedere la rappresentazione JSON dello stesso libro con ID 1234.


    A livello basilare vuol dire:
    - sfruttare gli url per rappresentare delle "risorse"
    - usare i verbi HTTP (es. GET, POST ecc...) per realizzare le classiche operazioni CRUD (create-read-update-delete)


    Esempio semplice: gestione di libri. Si stabilire un url che rappresenta la "collezione" dei libri es.
    http://blabla/api/books
    (nota, books al plurale!)


    GET http://blabla/api/books
    per ottenere la lista dei libri (eventualmente filtrata e/o paginata e/o ordinata usando appositi query param)

    GET http://blabla/api/books/1234
    per ottenere la rappresentazione del libro di ID 1234

    POST http://blabla/api/books
    per inserire un nuovo libro (rappresentazione del libro nel body della request)

    PUT http://blabla/api/books/1234
    per aggiornare il libro di ID 1234 (nuova rappresentazione del libro nel body della request)

    DELETE http://blabla/api/books/1234
    per eliminare il libro di ID 1234


    Se hai fatto qualcosa gi� di abbastanza/molto diverso da una cosa del genere .... non � REST ..... � HTTP usato a casaccio ...
    Okay forse sto cominciando a capire.
    io potrei avere anche una sistema complesso alle spalle e presentare solo alcuni metodi come servizi rest per fornire determinare risorse al client in XML o JSON, corretto?


    tornando al mio esempio:
    Espongo che mi ritorna il saldo con GET, acquisisco in dati dal client, eseguo l'interrogazione al DB con metodi e classi "interni" al sistema (intendo non esposti al web) e ritorno il risultato al client come JSON o XML.
    Giusto?

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2020 vBulletin Solutions, Inc. All rights reserved.