Comunicazione API RESTful tra più server Web

Question

Comunicazione API RESTful tra più server Web

#1 da (1 voti)
#2 da (0 voti)

6

Sto cercando di capire la comunicazione RESTful, ma ho ancora qualche dubbio.

Houn'applicazionewebprincipale(sullatodestrodell'architettura)realizzatainAngularJS,chemostraidatiprovenientidapiùserverWebcontenentialtreapplicazioniodatabase(sullatosinistro).Alcunediquesteapplicazioninonhannoun'APIRESTealcunelofanno,quindihoimmaginatodiinserireun'interfacciaAPIRESTtraquelleapplicazioniel'applicazionewebAngularJSavrebbefacilitatoillavoro.

IlmioproblemaèchenonconoscobenequelleAPIRESTdalleapplicazionisullatosinistro.

Lamiaattuale"soluzione" per questo è registrare ogni applicazione, inclusi i suoi endpoint, risorse, ecc. Supponendo che alcuni di questi endpoint utilizzino SSE (Server Sent Events) e altri semplicemente visualizzino dati specifici, penso di qualcosa di simile in questo modo:

Separo gli endpoint da quelli che offrono SSE in modo da poter applicare il lopping lungo in angularjs, oltre che con metodi, in modo da utilizzare solo quelli relativi a GET per ottenere dati e PUT per aggiornare, e così via .

Le mie domande sono, ha senso? È questo il modo giusto per farlo?

Sono consapevole che se alcune di quelle applicazioni hanno già una API REST, potrei accedervi direttamente usando $ http o ngResource in AngularJS. Ma cosa succede se non conosco completamente questa API REST o se non è stata ancora eseguita?

Grazie!

api rest angularjs

posta vak 15.11.2016 - 01:25

fonte

2 risposte

Leggi altre domande sui tag api rest angularjs

Flusso di lavoro per una forcella Github con modifiche compatibili e incompatibili sass: usa selettori astratti o mixin / segnaposto?

score 1 · Answer 1

Dato che hai molte incognite riguardo ai servizi downstream con cui stai interagendo, potrebbe essere logico creare i tuoi servizi REST che vivono accanto alla tua applicazione AngularJS. Ciascuno dei vostri endpoint potrebbe quindi delegare ai servizi downstream e aggregare le risposte in modo appropriato. Ciò impedirebbe anche all'utente di apportare modifiche al livello dell'interfaccia utente se si aggiungono / modificano i provider di servizi downstream.

Se hai creato un backend basato su Java qualcosa come il cammello Apache potrebbe essere utile: link

score 0 · Answer 2

Sembra che ci siano due diversi argomenti qui, quindi ne discuterò entrambi.

Configurazione dei gestori web

Dalla tua parte, sì, sembra che tu abbia un progetto chiaro in mente, e non vedo alcun problema con il modo in cui lo hai fatto. Come hai detto tu, è solo questione di comprendere le applicazioni web.

Se l'app web ha nascosto le sue chiamate REST interne, probabilmente non sarai in grado di raccogliere molte informazioni a riguardo se non è disponibile pubblicamente, ad esempio in una guida per l'utente PDF per la particolare applicazione.

Altrimenti, potresti controllare se ogni pulsante o collegamento sembra chiamare un servizio web e copiare quell'URL dell'endpoint, quindi incollarlo nella barra degli indirizzi del browser e andare da solo per esaminare i dati non elaborati. Questo potrebbe darti un'idea migliore di come collegare la tua API REST ad essa.

Apprendimento di un'API REST non familiare

La maggior parte degli endpoint REST o delle API hanno una sorta di documentazione web incorporata che è piuttosto facile da consultare.

Ad esempio, se si desidera utilizzare l'endpoint

http://site.server.com/REST/fetchData?id=123

Potresti provare a navigare verso l'URL principale REST di livello superiore, che di solito ha una sorta di modo integrato per esplorare i diversi endpoint e, eventualmente, anche la documentazione per questi endpoint. ArcGIS lo fa automaticamente, immediatamente, senza alcuna configurazione speciale, quando pubblichi qualsiasi servizio.

http://site.server.com/REST

Questo è il caso di Apache Tomcat; pubblica una pagina GUI predefinita per ottenere informazioni generali su Tomcat stesso. Puoi accedervi, supponendo che Tomcat sia in esecuzione su un server denominato site.server.com, con questo URL:

http://site.server.com:8080

Tomcat viene sempre eseguito dalla porta 8080, almeno su HTTP non crittografato. A seconda di come è impostato, quella pagina potrebbe anche solo dire qualcosa come "OK, funziona!" che non è poi così utile se non per confermare che Tomcat è attivo e funzionante.