API Connect — The beginning
I had started to publish about DataPower earlier, and I intend to continue to share more knowledge about it. However, I will change my post priorities by the importance I have seen in API Management concept lately.
Before my API Connect journey, I suggest you read two good IBM articles, in which API Management and ESB purpose, and related operational responsibilities are discussed.
My API Connect journey began at the moment I thought my DataPower journey ends.
My mission: expose SOAP services into REST with JSON.
I had already created several routes using DataPower following that structure:
- filter requests;
- change the REST request methods such as GET and PUT to POST SOAP requests;
- transform my request to SOAP envelope with the “text editor” (hi IBM, kindly improve the layer of XSLT editing in DataPower);
- invoke SOAP services and routing the response and faults;
- transform response via XSLT to JSONX;
- transform JSONX to JSON.
Yes, something very easy…
When I went to publish into the production environment, a definition: The exposure for Internet APIs will be provided by API Connect.
I had even seen how to implement OAuth into DataPower, and at first, I had not understood how the concept of an API Management would interfere with my application. I still believed it would be much easier to make the transformations into an ESB and continue exposing the routes via DataPower … a mistake that I intend to show you during this series.
The work I did in DataPower Multi-Protocol ended up losing, but as time went by, I started to understand how DataPower and API Connect relate themselves. When we install API Connect into a Docker image, you could see that the DataPower image will also be present, and then the integration between these two tools will become clearer.
Well, I will finish this post here, the next I will explain a bit better the API Connect proposal.
See you next time!
PS: I intend to improve my written English, so if you find out some mistake, please, notify me.
