How to Invoke REST APIs From Zato Microservices
In this article, see how Zato services can invoke external REST endpoints.
Join the DZone community and get the full member experience.Join For Free
This article is a companion to an earlier post — previously, we covered accepting REST API calls and now we will look at how Zato services can invoke external REST endpoints.
Similar to how channels are responsible for granting access to your services via REST or other communication means, it is outgoing connections (outconns, as an abbreviation) that let the services access resources external to Zato, including REST APIs.
Here is a sample definition of a REST outgoing connection:
The Python implementation will follow soon but, for now, let's observe that keeping the two separate has a couple of prominent advantages:
The same outgoing connection can be used by multiple services
The configuration is maintained in one place only - any change is immediately reflected on all servers and services can make use of the new configuration without any interruptions
Most of the options of REST outconns have the same meaning as with channels, but TLS CA certs may require particular attention. This option dictates what happens if a REST endpoint is invoked using HTTPS rather than HTTP, how the remote end's TLS certificate is checked.
The option can be one of:
- Default bundle — a built-in bundle of CA certificates will be used for validation. This is the same bundle that Mozilla uses and is a good choice if the API you are invoking is a well-known, public one with endpoints signed by one of the public certificate authorities.
- If you upload your own CA certificates, they can be used for validation of external REST APIs — for instance, your company or a business partner may have their own internal CAs
- Skip validation — no validation will be performed at all, any TLS certificate will be accepted, including self-signed ones. Usually, this option should not be used for non-development purposes.
A sample service making use of the outgoing connection is below.
First, we obtain a connection handle, then the endpoint is invoked and a response is processed, which in this case means merely outputting its contents to server logs.
In the example, we use a constant user name and query string but in practice, they would be likely produced basing on user input.
Note the 'params' dictionary - when you invoke this service, Zato will know that 'name' should go to the URL path but all the remaining parameters will go to the request's query string. Again, this gives you additional flexibility, e.g. if the endpoint's URL changes from path parameters to query string, the service will continue to work without any changes.
Observe, too, that we are responsible for catching and handling potential exceptions arising from invoking REST endpoints.
Finally, because the outgoing connection's data format is JSON, you are not required to de-/serialise it yourself, the contents of 'response.data' is already a Python dict read from a JSON response.
At this point, the service is ready to be invoked - let's say, through REST, AMQP or from the scheduler - and when you do it, here is the output that will be seen in server logs:
Now, you can extend it to invoke other systems, get data from an SQL database or integrate with other APIs.
Start the tutorial to learn more technical details about Zato, including its architecture, installation and usage. After completing it, you will have a multi-protocol service representing a sample scenario often seen in banking systems with several applications cooperating to provide a single, consistent API to its callers.
Published at DZone with permission of Dariusz Suchojad. See the original article here.
Opinions expressed by DZone contributors are their own.