API Connect — First Steps
Take a look at the first post of this series about API Connect:
As I said before, API Connect acts as an API Manager offering aspects such:
- Swagger APIs specifications creation;
- APIs executions;
- APIs management and monitoring;
- API security and logs;
It is possible to create REST or SOAP APIs following Swagger specification… yes… you could create a SOAP API with Swagger… actually… almost that…
IBM API Connect uses Swagger to specify and execute an API. It could be confused, however, in the next posts, this idea would be more easily comprehended, DataPower architecture position as well.
In SOAP APIs, WSDL is still the start point to API creation, however, through this first input, API Connect encapsulates WSDL as a Swagger API.
In the next posts, we will learn more about disadvantages and complications of this approach.
I am using Swagger in other personal projects, and I have enjoyed it a lot, both for documentation and API First concepts. Although there is no unanimity regarding REST APIs specification, whether with APIary, Swagger or RAML, I started to have a sympathy for Swagger because of the ease of integration with Spring in Java, Groovy and now with Kotlin projects as well. It does not mean that it is a problem-free, complex, or critical solution.
The main point here is to understand that API Connect ONLY supports Swagger as an implementation. Even though API Connect interface supports component creation via drag and drop, it’s still interesting to keep in mind the basics of the Swagger specification because some bugs and issues from the Swagger code generation by placing components and configuring them.
Another interesting aspect is to realize that programming with API Connect at the code level is limited to Gateway Scripts with Java Script and XSLT.
There are other components will help the development such as: if, switch, throws, map, invoke, etc. In the next posts, we will learn more about them.
Also regarding API Connect, it is interesting to note that there is a difference of user profiles in the solution:
- Administration profile;
- API Developer profile;
- API Consumer profile
We’ll talk more about each of these aspects in the next posts, as well as the operating environments of each of them. One example is the Developer Portal, where organizations are managed to consume APIs, as well as subscribing by consumers.
I think some approaches will be clearer with examples, so I will stop here, and get ready for the next post where we will install API Connect via Docker, see you there…
