In the previous article we discussed the general topics around APIs and their history. Now that you are up to speed with APIs, it is time to understand how they are built. For this article we will be using Talend software to show you how to develop APIs. Besides the development you will also see how to automatically generate documentation on your APIs.

Talend API Designer

API development is such a broad term because APIs can be developed in hundreds of applications and/or programming languages. Luckily Talend has a great way to make your first step in the development process. They call it the API Designer, and this should be your starting point when developing APIs with Talend.

In the API Designer you can configure the skeleton of your API in a graphical user interface. This is a web application that runs in your Talend Cloud environment. One of the big advantages of this is that you can share the skeleton with anyone in your Talend Cloud environment so that they can see what you are working on. For CI/CD purposes you can add a Git repository and store your API definitions in one of the following formats:

  • OAS 3.0
  • OAS/Swagger 2.0
  • RAML 1.0

These standard formats contain all the information you configure for your API and all its endpoints. Let’s say for example you want consumers to access product data, you can create a product API with multiple endpoints like a GET endpoint to show products and a POST endpoint that creates a new product in the database. Things like what kind of Query Parameters a user can give when sending in a request are also stored in that standard format. Information like what Query Parameters are mandatory comes in handy when you publish the documentation because this gives the consumer of the API a clear view on the parameters that are allowed for your API. For example: you have an API documentation page where a consumer can go and read about the purpose of a particular API and also how to use it, key information such as the URI path or the parameters that are required.

Talend API Tester

Another nice feature that is also connected with the API Designer is the API Tester. It has similar functions as for example Postman, where you can test your API by sending requests to that API and examining the results. The API Tester even has a Maven plugin where you can automate tests from your command line interface by generating standard JUnit/Surefire reports and allows you to configure custom URLs that will get notified before and/or after a test is completed.

Talend Studio

After the API skeleton is configured properly you can proceed to the Talend Studio to start developing the API request and response with all its logic and functionalities. The good part of this is that you can easily use the skeleton by loading the API configuration from the cloud and then simply dragging it onto your canvas within the studio. This automatically loads the entire configuration you have made in the API Designer.

Based on the request that the consumer sends you can choose from hundreds of components to handle the request. For example, you can use a Java component to dynamically build a SQL query based on the request and then use that query to fetch data from a Snowflake Data Vault. Of course, you could use any other source to fetch the data that will be returned to the consumer in the API response.

When you have finished developing all the logic that needs to be in place you can proceed by configuring the response component within the studio. This lets you configure what kind of response you send back to the service consumer, whether it is in a JSON or XML format for example. Furthermore, you can also set the response headers in that component. Some often-used response headers are:

  • HTTP Method
  • Version
  • Content-Type
  • Status code
  • And more…

So now that you have completed the API job in the studio it is time to test if it works. The good thing about the studio is that you do not have to publish and deploy the API to test it. You can easily run the job within the studio, and on the API will be available via the localhost. This way you can quickly test the functionality of the API and see if it meets the requirements. One of the things that can pop up is the performance of the API, because it could take time to complete a large request when it returns many records. A good solution to consider is to paginate your response, which lets the consumer determine which part of the response needs to be returned and this lowers the pressure on your API performance.

In the next episode of the API Services series we are going to cover how AWS is used to deploy and run the APIs in the cloud, so stay tuned!

Are you interested in seeing API development in action? We would love to give you a live demo and answer all your questions. Feel free to contact us to get more information.

 

Contact