Mantenimento delle informazioni di stato nell'API REST

Naviga le tue risposte
2

Sto sviluppando un'API REST che accetta JSON utilizzando Spring Boot. Io uso Spring Security per l'autenticazione. Ho un caso d'uso in cui ho due servizi, uno per testare la connessione a un sistema di terze parti e l'altro per recuperare i dati dal sistema di terze parti.

  • api / sistema / connessione
  • API / Sistema / CustomData

Quando chiamo il primo servizio, controllo se riesco a collegarmi correttamente al sistema di terze parti. Se sì, restituisco un messaggio "Success" o "Failure". Quando provo a effettuare la seconda chiamata per ottenere dati personalizzati, mi aspetto che la richiesta di avere le informazioni di accesso al sistema di terze parti sia presente nella richiesta. Creo nuovamente una nuova connessione e recupero i dati personalizzati e restituisco i dati. Il problema con questo approccio è che creo oggetti di connessione ogni volta che consuma molto tempo per ogni richiesta.

Per evitare questo sovraccarico, dovrei cambiare la seconda richiesta in questo modo

API / Sistema / connessione /? / CustomData

Ma per fare ciò, cosa devo restituire nel primo servizio che verifica la connessione?

  1. Devo restituire la connessione stessa? È possibile convertire l'oggetto di connessione in un JSON e deserializzare quando arriva la seconda richiesta? È anche una cosa sicura da fare?
  2. Devo memorizzare in cache questa connessione a sistemi di terze parti sul lato server e restituire un ID univoco per ciascuna connessione? Ma questo non infrange la natura RESTful dell'API?

O c'è un approccio diverso su come posso affrontare questo problema.

TIA.

    
posta Venkatesh 04.02.2018 - 05:52
fonte

2 risposte

1

In questo caso particolare, non penso che tu abbia bisogno della prima richiesta affatto come @Ewan noticiaed.

Ma se si vede tale necessità, è possibile passare uno stato utilizzando un token di sessione (simile al token di autenticazione OAuth Bearer. Utilizzando questo token è possibile creare e mantenere una sessione sul proprio webservice, che può contenere alcune informazioni di stato tra richieste.

Ma per favore pensaci due volte. L'API REST è migliore senza alcuna gestione dello stato.

    
risposta data 04.02.2018 - 13:35
fonte
0

Ok, dalla mia esperienza. Si utilizza ApacheHttpClient per eseguire la richiesta alle API. La verifica della salute dell'API ha senso se si vuole sapere in anticipo. Ad esempio, esegui alcune operazioni batch, effettuando centinaia o migliaia di chiamate all'API.   Ma soprattutto ci sono i codici di risposta HTTP da API, timeout della connessione, eccezione per gestire il caso problematico. Quindi nessuno di solito fa due chiamate per verificare che la connessione sia corretta e quindi effettuare una chiamata che ti serve.   Per quanto riguarda la creazione di una connessione, controllare la libreria ApacheHttpClient 4.0. C'è il gestore delle connessioni lì. Se hai bisogno di molte chiamate, allora il thread potrebbe essere utile. Se occorrono 250-400 ms per ottenere una risposta, potresti avere 50 chiamate parallele per ottenere 50 risposte per lo stesso tempo.

    
risposta data 05.02.2018 - 21:27
fonte

Leggi altre domande sui tag

Va bene simulare o stubare le librerie in lingue debolmente tipizzate? Sviluppo di app Salesforce in Ruby on Rails [chiuso]