Nimbostratus
NimbostratusThanks Chris! This is what I am trying to do:
Consider a server side service discovery infrastructure. Say I have a legacy web logic application (standard 3 tier application) that wants to make a RESTful call to microservice A running inside a docker container in Kubernetes. Say the Service Registry is Consul and my load balancer is a F5 BIG IP. The legacy application is not containerized. It is outside of Kubernetes.
Say that I also used Consul template to create a BIG IP config file that BIG IP will read from and reload whenever the config file changes. So BIG IP knows the physical location of microservice A.
What I am struggling to understand is how this pattern maintains the integrity of a REST architecture.
The legacy application will hit the BIG IP with an HTTP request like: https://[IP address of BIG IP]:port/?optional_query_string. The actual REST URI can only then be in the message body. Am I correct?
Unless I am writing some BIG IP scripts, there is no way that BIG IP will know what the intent of the call is by the legacy application. The scripts would have to parse the HTTP body and extract the intended REST request, create an HTTP REST request and then call the microservice A. When the response arrives from A to BIG IP, BIG IP will forward that to the legacy app through the http connection from the original request.
Am I getting the fundamental understanding right? So to me BIG IP needs to be REST aware. The online blogs on this pattern never explicitly say this but isn't that what needs to happen? The whole message transfer from legacy application to microservice A using a load balancer is assumed but never discussed.
Can you shed some light please or correct me where I am wrong? How can this pattern be adjusted so that it works for my use case?
Many thanks, Sajjad