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

Architecture 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!

2 Answers 2


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/

  • I would recommend this anyway. It removes any X-Origin headaches and adds a layer of indirection and abstraction, decoupling your application from the 3rd party service.
    – RubberDuck
    Apr 17, 2017 at 22:27

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


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.


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:


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.