Comunicazione tra Rest WebServices

[acronalb]

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.

[andbin]

è 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.

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.

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 ...

[acronalb]

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?