0% found this document useful (0 votes)
812 views

DIY Exercise 4-1 - Implement A REST API Using APIkit

This document provides instructions for implementing a REST API using APIkit in Mule. It involves: 1. Generating flows from an existing RAML specification using APIkit. 2. Implementing GET /accounts to retrieve account data from a database and transform it to the defined Account object format. 3. Enhancing the RAML specification to add a /accounts/{id} resource for retrieving, updating, and deleting individual accounts. 4. Regenerating the API implementation flows based on the updated RAML and implementing GET /accounts/{id} to retrieve a single account by ID.

Uploaded by

Rakkammal Rama
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
812 views

DIY Exercise 4-1 - Implement A REST API Using APIkit

This document provides instructions for implementing a REST API using APIkit in Mule. It involves: 1. Generating flows from an existing RAML specification using APIkit. 2. Implementing GET /accounts to retrieve account data from a database and transform it to the defined Account object format. 3. Enhancing the RAML specification to add a /accounts/{id} resource for retrieving, updating, and deleting individual accounts. 4. Regenerating the API implementation flows based on the updated RAML and implementing GET /accounts/{id} to retrieve a single account by ID.

Uploaded by

Rakkammal Rama
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

DIY Exercise 4-1: Implement a REST API using APIkit

Time estimate: 2 hours

Objectives
In this exercise, you implement a REST API that has a RAML specification. You will:
• Use APIkit to create implementation flows.
• Add logic to APIkit auto-generated flows.
• Enhance an API and regenerate the flows using APIkit.

Scenario
A RAML specification for an Accounts API has been published to Anypoint Exchange. You need to
implement this API using Anypoint Studio. Account data should be retrieved from the flights_customers
database and then transformed to match the Account data type defined in the Accounts API. After you
finish implementing the API, the requirements change and you need to extend the existing RAML
specification and modify the API implementation.

Use Anypoint Studio and APIkit to create the API implementation from the API
Create a new Anypoint Studio project that includes your API solution from exercise 3-1 or use
/files/module03/accounts-mod03-api-solution.zip (in the MUFundamentals4.x DIY Files zip that you can
download from the Course Resources).

Create a new API interface Mule configuration file by right-clicking the API RAML file and selecting
Mule > Generate Flows from REST API. Leave the HTTP Listener's path as /api/*.

Debug the auto-generated Mule application and use the APIkit Console to make GET requests
to http://localhost:8081/api/accounts. Be sure to set the required headers and query parameters.

Use a REST client such as Advanced Rest Client to make valid GET requests
to http://localhost:8081/api/accounts and remember to set any required headers and query parameters.

Answer the following question


• How does the APIkit router set the HTTP Listener to accept any endpoint?

Implement GET /accounts to retrieve account data from the accounts database
Implement the functionality to return all customer data from the flights_customers database using the
following MySQL database credentials:
• Host: mudb.learn.mulesoft.com

1
• Port: 3306
• User: mule
• Password: mule
• Database: training
• Table: flights_customers
Add additional logic to only return accounts that match a particular type (business or personal). Use an
input parameter to safely pass the account type to the database SELECT statement.
Note: For GET /accounts, you DO NOT need to implement the optional query parameters for name and
country. However, if you want to implement these query parameters, you can use the Choice router to
implement different query scenarios (which is covered later in Module 9 in the Fundamentals course).
You also do not need to implement anything for the Request-ID header.

Answer the following question


• What is the data type and format of the database results?

Map results from the database to Account objects


Transform the database results to match the Account schema specified in the accounts-api.raml file.
Here is an example of the desired transformed output:
[
{
"id": "100"
"firstName": "Alice",
"lastName": "Green",
"address": "77 Geary St., San Francisco"
"postal": "94108"
"country": "USA",
"creationDate": "2018-10-01T23:57:59Z+0:00",
"accountType": "business",
"miles": 1000
}
]

Hint: You can use the DataWeave splitBy and joinBy functions to split the name into a first name and a
last name. Assume that any word after the first space in the name is the last name.

Enhance the API specification for new requirements

2
Even though you have already started implementing the API implementation, requirements suddenly
change; your key stakeholders now want the API to manage specific accounts, with the ability to
retrieve and modify one account based on the account id.

Modify the Accounts API RAML specification with the following new requirements:
• The API has a nested resource /accounts/{id}, where id is a URI parameter that should match
the accountID column of the flights_customers database.
• The /accounts/{id} resource has an optional type query parameter.
• The /accounts/{id} resource has a GET method that returns an Account object in JSON format.
Note: Don't duplicate the definition of the Account data type in /accounts/id, because the type query
parameter is now optional. Create a new data type.
• The /accounts/{id} resource has the following additional methods:
o A PUT method that returns a JSON message:
{"message": "account replaced (but not really)"}
o A PATCH method that returns a JSON message:
{"message": "account modified (but not really)"}
o A DELETE method that returns a JSON message:
{"message": "account deleted (but not really)"}
• Each method should have a description.
• Each method should have a custom 400 message error.

Update the API in Anypoint Exchange


Publish the new version of the API to Anypoint Exchange and update the public portal.

Regenerate the API implementation


Use APIkit to regenerate the implementation for your updated RAML file.
Note: There was a bug for certain versions of Anypoint Studio that caused duplicate flows to be created
when an API was reimported from Design Center. If this happens to you, undo the step and then
directly import the RAML files into Anypoint Studio and do not import them from Design Center.

Answer the following question


• What happens to the existing APIkit-generated private flows?

Implement GET /accounts/{id}


After you regenerate the flows, add functionality to implement the /accounts/{id} resource's GET
method. In the flow, get all rows from the flights_accounts database where the accountID matches the
supplied id URI parameter, then transform the result to an Accounts JSON object (as specified in the

3
project's datatypes/account.raml file). Use an input parameter in the SQL to safely pass in the account
ID to the SELECT query.

Answer the following question


• How does APIkit implement the id URI parameter?

Verify your solution


Load the solution /files/module04/accounts-mod04-api-implementation-solution.jar (in the
MUFundamentals4.x DIY Files zip that you can download from the Course Resources) and compare
your solution.

You might also like