RESTful API communication between multiple web servers

Question

I'm trying to understand RESTful communication, but I still have a few doubts.

I have a main web application (on the right side of the Architecture) made in AngularJS, which shows data coming from multiple web servers containing other applications or databases (on the left side). Some of these applications don't have a REST api and some do, so I imagined putting a REST api interface between those applications and the AngularJS web app would facilitate the work.

My problem is, i don't properly know those REST api from the applications on the left side.

My current "solution" for this, is to register each application, including its endpoints, resources, etc. Assuming some of those endpoints use SSE (Server Sent Events) and some others just display specific data, I though of something like this:

I separate the endpoints from the ones offering SSE so that I can apply long lopping in angularjs, as well as per methods, in order to use only the ones related to GET to obtain data, and PUT to update, and so on.

My questions is, does this make sense at all? Is this the right way to do it?

I'm aware, that if some of those applications already have a REST api , I could access it directly using $http or ngResource in AngularJS. But what if I don't entirely know this REST api, or what if it hasn't even been done yet ?

Thank you!

Answer 1

Since you have a lot of unknowns regarding the down stream services you are interacting with it might make sense to create your own REST services that live along side your AngularJS application. Each of your endpoints could then delegate to the downstream services and aggregate the responses as appropriate. This would also prevent you from having to make changes to the UI layer if you add/change downstream service providers.

If you created a Java based backend something like Apache camel could be benefitial: http://camel.apache.org/

Answer 2

It looks like there are two different subjects here so I'll discuss both.

Setting up web handlers

On your side, yes it looks like you've got a clear design in mind, and I don't see any problem with how you've done it. Like you said, it's just a matter of understanding the web applications.

If the web app has hidden its internal REST calls, you will probably not be able to gather much information about it unless it's publicly available, say in a PDF user guide for the particular application.

Otherwise, you could check if each button or link seems to call a web service and copy that endpoint URL, then paste it in a browser's address bar and go there yourself to look at the raw data. That might give you a better idea of how to hook up your REST API to it.

Learning an unfamiliar REST API

Most REST endpoints or API's have some kind of built-in web based documentation that is pretty easy to browse.

For example, if you wanted to use the endpoint

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

You could instead try navigating to the higher level REST parent URL, which would usually have some kind of built-in way to browse the different endpoints, and possibly even documentation for those endpoints. ArcGIS does this automatically, out of the box, without any special setup, when you publish any service.

http://site.server.com/REST

This is the case with Apache Tomcat; it publishes a default GUI page for you to get general information about Tomcat itself. You can get to it, assuming Tomcat is running on some server named site.server.com, with this URL:

http://site.server.com:8080

Tomcat always runs from port 8080, at least over unencrypted HTTP. Depending on how it's set up, that page might also just say something like "OK, it works!" which isn't all that helpful except to confirm Tomcat is up and running.