• Curie solved one more puzzle (21 vs 20) and needed slightly fewer total attempts (36 vs 37).
• Curie hit fewer timeouts (5 vs 9) and won more of the notable speed comparisons (3 vs 2) — including a ~30× gap on Day 11 Part 2.
• Claude had the higher first-try success rate (75% vs 67%).
• Claude’s failure mode was deeper: when it got stuck, it’d keep producing more attempts indefinitely without recognizing the puzzle was a bad fit for DataWeave. Curie was the only one that actually called that out.

Full breakdown below.

I spent a few days running Advent of Code puzzles through two AIs side by side, asking each one for a DataWeave solution and tracking what came back. I noted the results for every attempt, and saved the actual code or write-ups for some of the more interesting failures. The repo lives here, and this post is a tour of what came out of it.

The contestants:

• Claude — Opus 4.7 in Claude Code, MAX effort mode (longer think times, higher cost).
• CurieTech AI — a MuleSoft-specialized AI, accessed via the curie-dataweave MCP server or directly at platform.curietech.ai.

Same input, same expected output, same DataWeave target. Each puzzle gets two transform.dwl files plus a benchmark/transform.dwl that runs both through dw::util::Timer::time() so the execution times sit next to each other.

The setup

A quick note on what “took too long” means in the notes, since it comes up a lot: the DataWeave VS Code extension on my machine times out at 50001ms. When a script exceeds that, I marked it as a timeout rather than falling back to the DW CLI to rescue it — the comparison is about how performant each AI’s solution is, and a script that only finishes via CLI doesn’t really answer that question.

The Playground links in the README run the timing scripts in a browser, but the Playground has its own ~2.5s request timeout, so the slower puzzles have to be benchmarked from VS Code instead.

The numbers 📊

Across 23 puzzles (Days 1–11 × 2 parts + Day 12 Part 1):

Close on most of these — Curie solves one more puzzle and needs slightly fewer total attempts, while Claude has a higher first-try rate. The bigger gaps are on timeouts (Claude hit nearly twice as many) and on the few puzzles where execution time was actually worth comparing, where Curie usually came out ahead.

Shared mistakes

The two AIs had some surprisingly similar slip-ups.

On Day 3 Part 1, both of them returned a Python script the first time, despite the request being for DataWeave. I had to reply asking for DW specifically. To be fair, Python is probably the most common AoC language overall, so it’s not totally unreasonable as a first guess — it’s just not what I asked for.

On Day 5 Part 2, both AIs ran into the same DataWeave error on their first attempt and both fixed it on the second. That one isn’t a knock against either of them — it’s the kind of failure mode that’s hard to avoid when you can’t actually execute the code as you write it.

Curie did one variation of this that Claude didn’t: on Day 8 Part 1, it returned Groovy code and noted that Groovy would be more efficient than DataWeave. That’s true in some sense, but the entire repo is a DataWeave comparison, so I had to ask for the DW version specifically.

A Claude moment worth showing

On Day 10 Part 1, Claude tried to find the DataWeave CLI on my machine with:

find / -name 'dw' -type f 2>/dev/null | head -5; which dw 2>/dev/null; ls /Applications/ 2>/dev/null | grep -i dataweave

When I asked why, Claude said:

“I was trying to find a way to actually execute the DataWeave script so I could verify it produces the expected output (7 for the sample). Without mvn or a dw CLI available, I can’t run it locally — so I can only reason about correctness statically. Want me to keep hunting for a runner, or just hand off the script for you to run in your IDE?”

That’s a reasonable instinct: an agent that knows it can’t see the result of its own code is going to look for a way to run it. Claude doesn’t execute the DataWeave it generates, so it can’t iterate against real output, which is part of why its DW-specific syntax or runtime mistakes tend to need a second attempt to catch. Curie, being MuleSoft-specialized, gets fewer of those through on the first try.

What I do wonder, though, is why Claude didn’t reach for the curie-dataweave MCP server that was already installed in this Claude Code session. That server can run DataWeave through Curie, which is exactly the missing capability Claude was searching for. Filesystem-spelunking for dw was the first thing it tried; the MCP tool sitting right there in its toolbox apparently wasn't.

The two puzzles neither AI solved

Two puzzles defeated both AIs in DataWeave: Day 10 Part 2 and Day 12 Part 1. These looked less like “we got bored” and more like genuine ceiling-hitting on what DataWeave can do at this input size, and the two AIs handled the wall differently.

On Day 10 Part 2, Curie did something I appreciated: alongside its very first solution, it flagged that the brute-force backtracking would be exponential in the worst case, and offered two paths if the real input blew up — a Groovy ILP solver, or staying in DataWeave with memoization and tighter pruning. ✅ Pre-warning about scaling, before the slow run, is exactly the kind of thing that’s useful from an AI.

The actual attempts then went:

• Memoized DataWeave attempt: didn’t just time out, but crashed the DataWeave VS Code extension and required a restart.
• Groovy ILP solver: produced the correct answer (19293) in about 6.8s.
• A “faithful DataWeave port” of the Groovy solver: verified on the sample but couldn’t scale.
• A “hardened” DataWeave version with precomputed coefficients: also timed out.

Curie was honest about the Groovy detour, including the line:

“the 19293 was not produced by DataWeave.”

Which I quoted directly in the notes because it’s exactly the kind of self-honesty I want from an AI in this comparison. The puzzle is a Did Not Complete in DataWeave regardless, but at least nobody pretended otherwise.

Claude hit the same wall over four attempts on the same puzzle — first timed out, second was wrong, third and fourth timed out, and at that point I called it.

Day 12 Part 1 had a similar shape. Curie’s first two attempts both returned Stack Overflow. Max stack is 256 (DataWeave does have a recursion depth ceiling). On the third attempt it didn't return code at all — instead, it wrote out a detailed argument that the stack overflow is a symptom rather than the bug, that the real puzzle is a large-scale polyomino packing problem (~750 regions, grids up to 50×50, hundreds of pieces), and that DataWeave wouldn't solve this regardless of restructuring. It offered to build a Groovy or Python solver instead. That's a reasonable place to tap out.

Claude went five attempts deep on the same puzzle (four timeouts, one error) before I called it there too. So the two AIs hit the same wall, but Curie was the only one who actually recognized it — Claude would have kept producing more attempts indefinitely if I’d kept asking, without ever stepping back to say “this isn’t the right tool for this puzzle.”

The performance gap

When the execution times were actually different enough to be worth annotating, Curie won more often than Claude — three notable wins to two. The most lopsided ratio (meaning the gap where one AI was vastly faster than the other, not just a little faster) was Day 11 Part 2:

• Claude: ~6 seconds.
• Curie: ~0.2 seconds.

That’s roughly a 30× difference, and it came from Curie volunteering memoization proactively. Claude’s wins on Day 8 Parts 1 and 2 were much closer ratios (15s vs 24s, 17s vs 26s — only about 1.6×) but in absolute terms still real differences — its solutions there happened to be structurally more efficient.

So neither AI is universally faster. They reach for different optimizations, and which one matters depends on the puzzle.

What I took away

A few observations after watching this play out:

1. DataWeave specialization shows up in the small mistakes more than the big ones. Curie made fewer “this won’t compile” mistakes and reached for memoization and decomposition patterns more naturally. Claude solved a wider variety of problems on the first try, but paid a small tax for not being able to see whether its DW actually runs.
2. Claude’s failure mode tends to be deeper, not more frequent. Higher first-try rate, but when it gets stuck (4 attempts on Day 10 P2, 5 on Day 12 P1), it stays stuck longer. Curie tended to give up earlier — sometimes by switching languages, sometimes by writing an honest explanation of why the puzzle isn’t a good fit for DataWeave.
3. The honest explanations were genuinely useful. Curie’s “the 19293 was not produced by DataWeave” and its Day 12 Part 1 write-up about polyomino packing both saved me time, because they correctly identified what was happening rather than producing another attempt that wouldn’t work either.
4. DataWeave is a useful harness for this kind of comparison. Constraints like the 50001ms timeout, the recursion ceiling, and the lack of an easy escape hatch to a faster language mean you find out which AI knows the language specifically, rather than which one is generally good at algorithms.

That’s a wrap on the comparison. The full table, per-puzzle notes, and saved explanations from each AI are all in the README.

If you want to keep up with more AI vs AI matchups, I’ve got a YouTube playlist where I’ll be posting more of these head-to-head videos as they go up.

Two AIs, one DataWeave, 23 Advent of Code puzzles was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Whether you’re hesitant, curious, or totally unfamiliar with ACB, now is the perfect time to start playing with it — without having to fully switch yet. In this post, I’ll walk you through what I covered in my latest YouTube video: why I switched, how you can try it safely, and what tools make the transition smoother.

P.S. You can schedule a call with me to troubleshoot your ACB issues! 👇

ACB troubleshooting - Alex Martinez

🚀 ACB Is More Than Just a New IDE

ACB isn’t just “Studio inside VS Code.” It’s an entirely different developer experience — faster, more flexible, and integrated with powerful tools like:

• Cursor AI (VS Code-based IDE with AI agents)
• GitHub Copilot
• VS Code extensions
• Integrated terminal, source control, theming, and more

Plus, MuleSoft is now releasing features that are only available in ACB — like Agentforce Topics.

😬 Not Ready to Switch? That’s Okay.

I get it. Most of the MuleSoft community isn’t using ACB yet. I ran a poll recently with 130+ votes, and here’s what I found:

• 🧠 Only ~10% use ACB daily
• 🔁 ~27% use it “on and off”
• ❌ 39% tried it once or twice
• 😬 24% haven’t touched it at all

So if you’re still in Studio, you’re not falling behind — yet. But if you wait too long, you’ll be catching up when others are already building faster, cleaner, and smarter.

🛠️ How to Get Started with ACB (the Right Way)

I walk through the setup in detail in the video, but here are the key steps:

1. Install Git
2. Download Visual Studio Code
3. Install the Anypoint Extension Pack (do not install extensions individually!)
4. Restart VS Code if needed, and make sure everything is up to date
5. Start with something small — like designing an API spec

👉 If it’s not working, uninstall all ACB extensions, quit VS Code completely, and reinstall the extension pack after Git and VS Code are installed.

🤖 Using ACB with Cursor AI

If you’re already a Cursor AI user (or curious about it), good news: it supports the full ACB experience. In some ways, it’s even smoother than vanilla VS Code, especially when you start combining ACB with intelligent agents, code chat, and auto-generated logic.

Check out Cursor:

Cursor - The AI Code Editor

🧪 What Should You Try First?

• Design an API with RAML or OAS
• Open an example project like “Hello Mule” or a known custom policy
• Compare how the same flow looks in Studio vs ACB
• Experiment with themes, the activity bar, and extensions
• Try out Cursor AI if you’re feeling bold

🎯 TL;DR

You don’t have to drop Studio today — but you should start learning ACB now.

It’ll help you:

• Get ahead of your team when they’re ready to switch
• Access new MuleSoft features earlier
• Improve dev productivity with modern tooling
• Work smarter with tools like Cursor AI or GitHub Copilot
• Future-proof your career as the MuleSoft platform evolves

🙌 Need Help?

I’m here!
Drop a comment on the video: https://youtu.be/dlODB4cjXyU
Or connect with me on LinkedIn

Let me know what specific ACB tutorials you’d like me to make next. I’m happy to keep helping the MuleSoft community grow together. 💙

🔗 Related Links:

• Download Git: https://git-scm.com/downloads
• Download VS Code: https://code.visualstudio.com/
• Cursor AI: https://cursor.com
• ProstDev: https://www.prostdev.com

Why You Should Start Using Anypoint Code Builder (Even If You Love Studio) was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Please note that it is NOT an official theme. It’s just something I created on my own. I based most colors on the Anypoint Platform or other official sites under the MuleSoft.com domain. However, that doesn’t mean they’re the official colors :-) I just wanted to mention that.

That said…The theme is already published in the VSCode Marketplace. You can download it and start using it right away!

MuleSoft Community Theme - Visual Studio Marketplace

Contribute

You can start contributing via GitHub whenever you see something is missing or just not right. You can either create a Pull Request directly in the GitHub repository or raise an issue for me to take a look.

Overview

Ok, enough chatting. Let’s just see some screenshots!

So what do you think??

You can find more information like the color palette and the full list of sections that were customized for this theme in the Marketplace site.

I am always open to feedback. This was my first version of what I envisioned for this theme. And as you can see, I am not a designer! So, a lot of things can be improved for sure :)

Don’t forget to leave a review in Marketplace so I can improve it.

Oh! And this is just the light theme for now. I hope to create a dark theme in the future :D

Thank you!!

Alex

New MuleSoft Community Theme for Visual Studio Code! was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every year since 2021, I’ve been doing these 31 videos called #codetober!

See here the full list of videos for 2021–2023.

This year, the videos have been edited for your better digestion and are (almost all) less than 10 minutes each.

Please comment on our videos to suggest future content or ask any questions about a specific topic.

Happy codetober!!

💡 ​Find this year’s GitHub repository here: ProstDev/codetober23

Videos

Day 1: How to scaffold Mule flows from a published API spec in Anypoint Studio

Once you have your API specification and you have published it to Anypoint Exchange, you can now import this directly from Anypoint Studio to automatically scaffold the necessary Mule flows and error handling in a new Mule project.

Day 2: How to scaffold Mule flows from a published API spec in Anypoint Code Builder

Once you have your API specification and you have published it to Anypoint Exchange, you can now import this directly from Anypoint Code Builder (currently in BETA version) to automatically scaffold the necessary Mule flows and error handling in a new Mule project.

Day 3: How to RE-scaffold Mule flows from an Exchange API spec in Anypoint Studio

After doing some changes to the API Specification from Design Center, the API spec is published to Exchange with a new version. After that happens, you can download the new version to your Anypoint Studio and re-scaffold the Mule flows to have an up-to-date API implementation.

Day 4: Use MuleSoft’s visual API Designer to create a To-Do API specification

Did you know MuleSoft provides this neat Graphical User Interface (GUI) where you can configure your own API specification with just clicks? That’s right, you don’t have to learn RAML or OAS anymore. You can just follow this visual tool to create them and it gives you the code you need in whichever format you need it!

Day 5: DataWeave 2.5 module features: toString, concatWith, version

There was a new DataWeave version released this past October 3 (2023). Let’s check out what’s new with these three functions: toString, concatWith, and version.

Day 6: Exploring the Thunder Client Extension for Visual Studio Code

I was using the Postman extension for VS Code but I kinda liked this one better 👻 it’s more lightweight even though it doesn’t offer all the great options Postman does. But it’s great for quick testing!

Day 7: How to create custom user snippets in Anypoint Code Builder (VS Code)

User Snippets are important to keep handy your most used components in ACB!

Day 8: Exploring the GitHub Actions Extension for Visual Studio Code

This is a good add-on for VS Code if you’re using a lot of GitHub Actions for your projects!

Day 9: How to deploy to CloudHub 2.0 with the Mule Maven Plugin & Connected App

It took me a while to get this going!

Day 10: How to use DataWeave 2.5 with the BETA extension in Visual Studio Code

DATAWEAVE 2.5 HAS BEEN RELEASED FOR VSCODE AAAAAHHH 🤩

Day 11: 8 examples to import modules/functions in DataWeave & how to use aliases

Using the `import` keyword, you can just import a module and then call the function like `Module::function()`, or you can use the `from` keyword to specify the functions to import.

For example, `import * from Module` or `import function from Module`.

Then, we have other interesting approaches like using `as` to create aliases for the modules or the functions.

Like, `import Module as Mod` or `import function as f1 from Module`

Day 12: Help us get DataWeave into Exercism for programming challenges/exercises

Exercism provides coding exercises for you to learn a variety of programming languages. DataWeave is currently NOT one of them though. However, not all heroes wear caps! Join our community member Clayton Flesher in this quest to get DW on this platform!

Day 13: How to run several Mule applications in Anypoint Studio at the same time

To run more than 1 Mule app at the same time in Studio, first, you have to make sure your HTTP listeners are running in different ports. Otherwise, the applications won’t run at the same time because the port is already in use in your local.

After you change the ports, you can use the Run Configurations option and create a new Configuration to run all the apps at the same time. Make sure you use different ports locally but you still use the dedicated ports when you deploy to CloudHub (i.e., leave ports 8081 for CH but change them for local).

Day 14: Best practices in Mule apps: global elements & properties files per env

After creating our three Mule apps (from the previous video), we now have to set up the best practices so we can set up the different configurations for the dev and local environments to make our lives easier in the future.

1️⃣ We start by setting up the global.xml Mule Configuration File to save all the Global Element Configurations so we don’t have to be looking for them in other XML files. It may not seem like a big deal for a small project like this, but once you have more files and flows, it can become a nightmare.

2️⃣ After that, we set up different properties files per environment — one for dev (what we’ll deploy in CloudHub) and one for local. Don’t forget to set up the ${env}.properties or ${env}.yaml configuration for the properties files and the `env` global property set to `local`. And ta-da! We are ready to get started on the next step: calling each layer separately.

Day 15: Setting up HTTP Requests for Experience, Process, & System layers in Mule 4

In the previous two videos, we set up three very basic Mule projects to represent the 3 API-Led Connectivity layers: Experience, Process, and System.

If you’re not familiar with this approach, it means that the client application is gonna call the Experience-layer API, which is then gonna call the Process-layer API, which is finally gonna call the System-layer API.

Client ➡️ Experience API ➡️ Process API ➡️ System API ➡️ Server

It has its reasons why, but we’re not focusing on that now. We just want to set up the HTTP requests from E (or X) to P and from P to S. Along with that, we are making sure our local and dev properties are up to date.

The dev properties are always running in port 8081 while the local properties have to be split in ports 8081, 8082, and 8083 (can be other ports, these are just used as an example).

Day 16: How to debug several Mule applications in Anypoint Studio at the same time

In case you haven’t debugged Mule apps before, or in case you haven’t debugged more than one Mule app at the same time before, this video is perfect for you!

In previous videos, we had set up the Run Configurations to be able to run the three Mule apps that we’ve been using in these examples (Experience, Process, and System API layers from the API-Led Connectivity approach).

This time you can reutilize the same configuration but to DEBUG instead of just RUN. Apart from that, we encountered an error pretty quickly telling us that the HTTP response had resulted in a TIMEOUT because we halted the apps while debugging.

We learned how to set up some properties to increase the HTTP response timeout locally so that it lets us debug in peace 😌

Day 17: Deploy Experience, Process, & System API layers to CloudHub 2.0 from Studio

After setting up our three Mule apps for the Experience, Process, and System APIs (from API-Led connectivity), we are finally ready to deploy them to CloudHub 2.0 (in Runtime Manager) and finish setting up the properties for the dev environment ✨

We learned that the port for HTTP in CloudHub 2.0 has to be 80 and the port for HTTPS has to be 443! This works differently from CloudHub 1.0, where you can use port 8081. Interesting fact that I did not know about until now 🥹

Day 18: Designing the American Flights API Spec in Anypoint Code Builder (ACB)

After Anypoint Code Builder (ACB) has been GA’d, let’s go ahead and try out the different tutorials the team has created for us to get familiar with the tool.

In this video, we’ll use ACB to create an API specification widely used in the MuleSoft training called the American Flights API. We’ll learn how to reuse API fragments from Anypoint Exchange locally, how to use the data types from Exchange, and how to see it all reflected in the API console from ACB.

Day 19: Testing, syncing, and publishing an API in Anypoint Code Builder (ACB)

In the previous video, we designed an API Specification for the American Flights API.

In this video, let’s first test that our API is working as we would expect using the mocking service.

Then, we’ll sync the specification to Design Center so that we can access this same information from Anypoint Platform.

Finally, let’s publish this API to Anypoint Exchange so other people can consume it. All from Anypoint Code Builder!

Day 20: Integrating American Flights Processes in Anypoint Code Builder (ACB)

Let’s learn how to develop an integration in Anypoint Code Builder (ACB) by following the previous examples of the American Flights API.

In this video, we’ll create a simple Mule application with an HTTP Listener that will output a string payload. We will learn how to run this application locally to make sure it works properly.

Day 21: Connecting to a Database from the Mule app in Anypoint Code Builder (ACB)

We want to connect to the American Flights database so we can pull the details of the flights for our American Flights API.

In this video, we’ll learn how to set up the database configuration in the pom.xml and set it up in the Mule Configuration file. After that, we’ll test it to see if it works as-is or if we need some sort of transformation 👀

Day 22: Transforming Flight Data with DataWeave in Anypoint Code Builder (ACB)

We were able to connect to the Database in the previous video, but we weren’t able to get a successful response just by doing this.

In this video, we explore the Transform Message component in Anypoint Code Builder so we can correctly transform the data we receive from the database into the JSON structure we had defined in our API Specification.

Day 23: Implementing the American Flights API Spec in Anypoint Code Builder (ACB)

In this series of videos, we started by designing the American Flights API and then we developed some code to get the data from the database.

In this video, we are putting it all together. We can scaffold the flows from the API specification that was published to Exchange and then call the MySQL flow with a Flow Reference.

Day 24: Debugging the American Flights App in Anypoint Code Builder (ACB)

It’s very important to learn how to debug your code in Anypoint Code Builder (ACB) because it will give you more insights into what is happening in the flow of your application.

In this video, we’ll learn how to start a debugging session to test the app, how to add a watch expression to take a look at the payload’s media type, how to add, disable, or enable breakpoints, and how to stop debugging.

Day 25: Implement & test a GraphQL API in Anypoint Code Builder (ACB)

Even if you’re not familiar with GraphQL, you can generate/scaffold a whole Mule project based on a GraphQL schema that we publish in Exchange. After publishing the schema in Exchange, we can implement the API locally using Anypoint Code Builder in minutes!

Day 26: Using the Transform Message component (DataWeave) in Anypoint Code Builder

We know how to define metadata in Anypoint Studio to see a preview of our DataWeave code to transform the data using the Transform Message component. But how to do this in Anypoint Code Builder (ACB)?

In this video, we’ll use a Transform Message component in a Mule project to transform an input into an expected output according to our “business requirements.” Then, we learn how to create the payload.json input and how to run the script according to this JSON file. You can also use the Enable Autopreview button to get the same functionality from the DataWeave Playground!

Day 27: Using branches in Design Center & Anypoint Code Builder for API specs

Have you ever had to work on a single API specification but divide the work between more than 2 people? Isn’t it messy? You can use the branching system (or version control system) that Design Center provides for this type of scenario.

Whenever you work on a change to the API spec, you can create a new branch, make the changes, and then review the changes to merge to the master/main branch. You can do this same thing from Anypoint Code Builder (ACB) using the Source Control plugin from Visual Studio Code (VS Code). Here I’ll tell you how!

Day 28: Testing Mule flows with the MUnit recorder in Anypoint Studio

In MuleSoft, we use MUnit tests to make sure we create unit tests for our Mule flows and Mule projects. There is this tool called the MUnit recorder that runs your Mule application locally and records how you interact with it in order to create some tests.

In this video, we create a simple MUnit test to assert the expected output from what we send into the app. The app uses a Choice router and Set Payloads to see the different routes.

Day 29: Enable Multi-Factor Authentication in MuleSoft with the Salesforce App

When you sign in to Anypoint Platform, you can select to enable Multi-Factor Authentication (MFA) for your account to protect it from any dangers on the web 👀

In this video, we’ll learn how to enable MFA for Anypoint Platform using the Salesforce Authenticator app (available for iOS and Android devices).

Day 30: Differences between the DataWeave extension & Anypoint Code Builder

One thing is the DataWeave extension for Visual Studio Code which was mostly created for you to create new DataWeave libraries but can also be used instead of the online DataWeave Playground.

Another thing is Anypoint Code Builder (ACB), where you create Mule projects and can use DataWeave inside one of these projects.

You can use both of these tools independently or together. But what’s the difference then? In summary, you will have more DataWeave functionality if you install the DW extension and use it with ACB. You can also use ACB without having the DW extension, but there will be less functionality available for you. That’s why I’d recommend you to use both.

Day 31: Export a Mule project as a deployable JAR file in Anypoint Code Builder

A lot of times it’s just easier to export a deployable JAR file from your Mule project to upload it directly in Runtime Manager instead of using the IDE (whether it’s Studio or ACB) to deploy it from there.

Whichever it’s your preferred use case and method of deploying a Mule app into CloudHub or any other runtime plane, here is how you can export the Mule application into a .jar file from Anypoint Code Builder.

You can subscribe to my YouTube channel to get notifications as soon as I publish new videos!

#Codetober 2023 ~ 31 MuleSoft-related videos under 10min each! was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last session, we reviewed how to implement the articles logic, created a Postman collection with its local+dev environments, and learned how to debug our Mule application.

In this week’s session, we confirmed the API works locally, so we deployed it to CloudHub (located in Runtime Manager) to test it in the dev environment.

Note: The links and notes from the session have been added to the GitHub repository for you to follow through with what I’m doing in the video. You can find both recordings (the complete and the shorter one) at the end of the post.

Homework from the last session

In the last session, we had started our Postman collection and we did the articles requests. Your homework was to finish creating the other requests to match our API specification. You should now have something similar to this:

You can also just import the Postman collection from the repo here.

Testing locally

You can download this Mule project if you want to follow along with what we did in this session. In summary, the API already works for the articles and categories resources. We can run this application locally and use our Postman collection with the local environment to verify it works.

Once we have verified we do have the functionality we need, we can move on to deploying this app to CloudHub.

Deploying to CloudHub

We’re going to deploy this application manually from Anypoint Studio. For this, you have to right-click on your project and select Anypoint Platform > Deploy to CloudHub.

If you haven’t signed in to your Anypoint Platform account, it will ask you to sign in at this point.

If you experience some issues at this point, you can also go to Anypoint Studio > Settings and navigate to Anypoint Studio > Authentication.

You can remove and re-add your Anypoint Platform credentials and try to deploy again. Any issues should be fixed with this.

Make sure you have selected the latest runtime version and check the Object Store v2 checkbox.

Because we have different properties per environment (local and dev) in our Mule application, we have to make sure our environment property is correctly updated. In our case, we have to set the env property to dev.

After confirming those changes, you can deploy your application.

You can confirm that your application is being deployed in Runtime Manager. Once it’s running, you can retrieve the Public Endpoint to replace the URL in your Postman environment to test.

You can also find this CloudHub URL from the Dashboard view.

Once you have copied the URL, you can go to Postman and replace it in the dev environment. Make sure you add /api at the end of the URL. For example https://maxines-blog-p9b1jf.5sc6y6-1.usa-e2.cloudhub.io/api

Now you just have to switch the environment from local to dev in Postman and you’ll be able to test the requests in CloudHub.

Recordings

Finally, here are the two recordings you can find about this session.

• The complete video on Twitch
• The edited/clean/shorter version on YouTube

Here you can find the shorter version from YouTube:

And here you can find the complete video from Twitch (note that there are two videos this time because my internet was acting up so the live stream was split in two 🥹):

Please let me know if you have any comments, suggestions, or just general feedback for me!

MuleSoft from Start: A Beginner’s Guide — Session 7: Deploy the Mule App to CloudHub was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last session, we modified our newly created Mule project to follow best practices like having a specific file for Global Elements or creating properties files per environment.

In this week’s session, we reviewed how to implement the articles logic, created a Postman collection with its local+dev environments, and learned how to debug our Mule application.

Note: The links and notes from the session have been added to the GitHub repository for you to follow through with what I’m doing in the video. You can find both recordings (the complete and the shorter one) at the end of the post.

Homework from the last session

You can see the full list of changes I did for this solution in this Pull Request or read the step-by-step here. The homework was to:

• Create new Mule Configuration Files to keep each resources’ logic separate from the main maxines-blog-api.xml file. Like so:

• Add sub-flows inside these new config files instead of flows. For example:

• Reference these new sub-flows from the main flows from the APIKit router. Like so:

• Finish creating the logic for the articles resource (happy path).

• Improve the code to avoid duplicating the same code (like we do with the Retrieve connector named GET articles) -- this helps to prevent human error.

Postman collection

We ended up starting a Postman collection to keep all our basic requests to be able to test this API. We created the following requests:

We also created two different environments in Postman to be able to switch between local and dev (once we deploy the application to CloudHub).

You can download this collection we generated here.

Debugging a Mule app

It is important you learn how to debug your Mule application so you can see the flow of the app running step by step. It is also useful to understand better how your Mule message is being transformed in every component.

You can debug by adding a breakpoint to any component — this means the application will pause running in the spot where you put the breakpoint so you can advance and see step by step.

And instead of running the application, click on debug.

Make sure you change your perspective to be able to see the debugging windows.

Once the app has been started (you can confirm in the Console), you can send a request and see where it stops.

In the Mule Debugger window, you will be able to see a preview of the Mule message and other properties.

You can use the Evaluate DataWeave Expression window to run some DataWeave code and see a preview of the output without affecting the rest of the running application.

You can use the debugger control buttons at the top-right to be able to step into/out of or continue running the application.

Finally, you can change perspectives using the top-right buttons to change from development and debug views.

Recordings

Finally, here are the two recordings you can find about this session.

• The complete video on Twitch
• The edited/clean/shorter version on YouTube

Here you can find the shorter version from YouTube:

And here you can find the complete video from Twitch:

Please let me know if you have any comments, suggestions, or just general feedback for me!

MuleSoft from Start: A Beginner’s Guide — Session 6: Debug the Mule App in Anypoint Studio was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last session, we finished creating our API Specification, tested it, and published it to Exchange. After that, we used that asset from Exchange to create a Mule project with the scaffolded flows from the API Spec.

In this week’s session, we modified our newly created Mule project to follow best practices like having a specific file for Global Elements or creating properties files per environment. We also started the development of our API Implementation using the Object Store to keep our API data instead of connecting to an external database or a third-party service (for simplicity purposes).

Note: The links and notes from the session have been added to the GitHub repository for you to follow through with what I’m doing in the video. You can find both recordings (the complete and the shorter one) at the end of the post.

Global Elements file

Right-click on src/main/mule and create a new Configuration File. Name it global.xml. We will use this file to keep the Global Elements from the whole project inside just one Configuration File, instead of having them spread across different files.

Now go back to the main Configuration File that was created before (with the APIKit router), go to the XML view, and cut the two configurations for the HTTP Listener and for the Router. You will paste these into the new global.xml file, inside the <mule></mule> brackets.

That’s it! Moving on, you will be able to use this global.xml file to keep all the Global Elements. This will save you time in the future so you don’t have to look into all the Configuration Files to find your Global Elements.

Properties

There are certain values that you don’t want to keep hardcoded into the XML code in case you want to change them later. For example, the HTTP host or port. Besides that, you want to be able to have different values depending on the environment the application is running in. For this purpose, it is recommended to have different properties files located under src/main/resources.

Note: The properties files can be of type .properties or .yaml, but in this example we’re going to use .properties.

Right-click on src/main/resources and create two new files: dev.properties and local.properties.

Inside the local properties file, add the following properties:

http.host=0.0.0.0
http.port=8082

Inside the dev properties file, add the following properties:

http.host=0.0.0.0
http.port=8081

Now you can go to the Global Elements and edit the HTTP Listener configuration to refer to the properties we just created using the syntax ${property}. Like this:

In order for the Mule app to know which configuration file should it take depending on the name of the environment, we’re gonna have to add a few more configurations to connect all of these files.

In Global Elements, create a new Global Property with the name env and the value local. This way, every time we run this Mule app, it’s gonna know the environment is local. When we deploy this application to the cloud, we are going to create another property there to tell it the environment is now dev.

The final step is to actually add the files to read depending on this env property. To do this, create a new Global Element that is a Configuration Properties. In the File field, write ${env}.properties

This configuration will now read the value from the env property we set up (either local or dev), and replace it in the ${env} part to end up with either local.properties or dev.properties.

Developing the API

We decided to use the Object Store to keep our data instead of spending time creating a database, just for the sake of simplicity. During the video, we finished implementing the logic for GET /articles and POST /articles. In other words, to read all the articles and to post a new article.

This is the configuration we ended up creating for the GET:

<flow name="get:\articles:maxines-blog-api-config">
  <logger level="INFO" message="Starting GET /articles" doc:name="START" />
  <os:retrieve doc:name="GET articles" doc:id="d86a63ee-6e86-4301-b189-2c79f606f52c" key="#[Mule::p('os.articles')]" objectStore="Object_store" >
    <os:default-value ><![CDATA[#[output application/json --- []]]]></os:default-value>
  </os:retrieve>
  <logger level="INFO" doc:name="END" doc:id="be2cfaf5-dd3f-473f-97dc-2f46323b9230" message="Ending GET /articles" />
</flow>

And for the POST:

<flow name="post:\articles:application\json:maxines-blog-api-config">
  <logger level="INFO" message="Starting POST /articles" doc:name="START"/>
  <os:retrieve doc:name="articles" doc:id="86c79bf7-248f-452d-afde-1f5605d69937" key="#[Mule::p('os.articles')]" objectStore="Object_store" target="articles">
    <os:default-value ><![CDATA[#[output application/json --- []]]]></os:default-value>
  </os:retrieve>
  <ee:transform doc:name="append new article" doc:id="db752066-af0c-4635-9f1f-9340d20aef67" >
    <ee:message >
      <ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
(vars.articles default []) + payload]]></ee:set-payload>
    </ee:message>
  </ee:transform>
  <os:store doc:name="new article to 'articles'" doc:id="92d29f4d-58d7-4130-924b-32df7ae1be16" key="#[Mule::p('os.articles')]" objectStore="Object_store"/>
  <remove-variable doc:name="articles" doc:id="72fe56a1-3265-4982-a670-98eaaebd0459" variableName="articles"/>
  <logger level="INFO" doc:name="END" doc:id="0fefc982-dc69-4f25-bf9b-0b7ebbec86e2" message="Ending GET /articles"/>
</flow>

Homework

For you to practice — and because I can’t do it all in the 1-hour live stream :’D — we’ll work on the following things offline:

• Create new Mule Configuration Files to keep each resources’ logic separate from the main maxines-blog-api.xml file
• Add subflows inside these new config files instead of flows
• Reference these new subflows from the main flows from the APIKit router
• Finish creating the logic for the rest of the resources (we just did articles in this session)
• Improve the code to avoid duplicating the same code (like we do with the Retrieve connector named GET articles) -- this helps to avoid human mistake

I will post my homework solution before July 12 and we’ll meet again on July 19 to continue with the sessions :)

Recordings

Finally, here are the two recordings you can find about this session.

• The complete video on Twitch
• The edited/clean/shorter version on YouTube

Here you can find the shorter version from YouTube:

And here you can find the complete video from Twitch:

Please let me know if you have any comments, suggestions, or just general feedback for me!

MuleSoft from Start: A Beginner’s Guide — Session 5: Develop the API in Anypoint Studio was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last session, we started creating an API specification using the UI in Design Center. We designed the data types and the articles resource. Our homework was to finish the API specification for this session.

In this week’s session, we finished the design of our API specification, tested and adjusted it, to finally publish it to Exchange. After publishing to Exchange, we scaffolded the necessary flows from Anypoint Studio using the APIKit Router so we don’t have to start our Mule application from scratch.

Note: The links and some notes from the session have been added to the GitHub repository for you to follow through with what I’m doing in the video. You can find both recordings (the complete and the shorter one) at the end of the post.

Homework from the last session

After careful consideration and because I’m already experienced in RAML, I decided to move away from the GUI and design my own specification using RAML 1.0 directly (still in Design Center tho). This is the list of resources I ended up with:

/articles
/articles/{id}
/articles/{id}/comments
/articles/{id}/comments/{id}
/writers
/writers/{id}
/categories

I decided to use a query parameter on the /categories resource to query if a specific category (string) exists or not. A similar approach would be done with the comments. If you don't want to have such a long URI like /articles/1/comments/1, you can also decide to use query parameters instead. This is completely up to your design/preference.

Test your API Specification

Once you have a base specification, you can start testing how the experience would feel for the developers using your API. To do this, you first have to click on an HTTP method from the right (in Design Center).

Then, you can click on the Try it button.

This will let you send any Query Parameters or Headers in the request but since this is a GET method, we don’t have to send anything and we can just click on Send.

After clicking Send, we’ll receive the example we had set before.

It is important to know that this is not a working application, it is just a mock that will return the examples you set in the API specification. This is just so you can double-check all the specification details and make sure the design is correct.

Test the rest of the methods to make sure they’re working as expected or make adjustments if needed before we publish it to Exchange.

Publish to Exchange

Once you’ve made sure the specification is ready, you can click on the Publish button at the top right, leave the versions as they are (1.0.0 and v1), select the Stable state, and click on Publish to Exchange.

That’s all! We can now create our Mule project in Studio.

Anypoint Studio

You can download Studio from here and see the installation instructions here. Once it’s installed, click on Create a Mule project, add your project name, and import the published API from Exchange.

Make sure you are logged in to your Anypoint Platform account and search for the API Specification you just published to Exchange. Click on the Add > button in the middle of the window and click on Finish.

Once the scaffolding is done, you will have your Mule project with the APIKit router and the necessary flows to continue your implementation.

You can test your new Mule application by running it locally (right-click on the canvas and select Run project…).

Once you see the DEPLOYED message in the console, you can open a terminal window and send a request using curl. You can also use Postman or your browser if you don’t want to use the terminal.

curl localhost:8081/api/articles

You may not get a response back because we haven’t implemented any changes, but you can check the console for new lines being logged.

Recordings

Finally, here are the two recordings you can find about this session.

• The complete video on Twitch
• The edited/clean/shorter version on YouTube

Here you can find the shorter version from YouTube:

And here you can find the complete video from Twitch:

Please let me know if you have any comments, suggestions, or just general feedback for me!

MuleSoft from Start: A Beginner’s Guide — Session 4: Test & Publish the API Specification was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last session, we learned the basics of an API and API-Led Connectivity.

• Analogies and Examples
• HTTP Methods
• URI
• Query Parameters
• HTTP Status Codes
• API-Led Connectivity

In this week’s session, we started designing our own API Specification for a blog API. Let’s see a summary of what we did!

Note: The links and some notes from the session have been added to the GitHub repository for you to follow through with what I’m doing in the video. You can find both recordings (the complete and the shorter one) at the end of the post.

Requirements

Before jumping right into Anypoint Platform, we first created our requirements on a text file to have a clearer image of what we’re trying to make. We created some resources and data types.

We defined resources as “the nouns of our APIs — stuff we can use a CRUD operation on.”

CRUD

• Create
• Read
• Update
• Delete

Resources

• Articles
• Writers
• Categories
• Comments

Data Types

- article
    - id
    - slug
    - title
    - content
    - writerId
    - categoryId
    - comments
- writer
    - id
    - name
    - bio
    - articles
- category
    - id
    - name
    - articles
- comment
    - id
    - content
    - author
    - articleId
- error
    - code
    - description

After creating our notes, we were now able to start creating our API Specification in Design Center.

Design Center

In your Anypoint Platform account (you can use a free trial), go to Design Center and create a new API Specification. Make sure to select the Guide me through it option. Especially if you’re not familiar with RAML or OAS.

In the API Summary window, select the following values:

• Title = Blog API
• Version = 1.0.0
• Protocols = HTTP, HTTPS
• Media type = application/json
• Base URI = /
• Description = # Welcome to Maxine’s Blog!

Data Types

In the Data Types section from the left side of the screen, click on the + button to start creating more items. Create the following data types with the properties listed below.

Comment (Object)

• id — Required — Number
• content — Required — String
• author — Required — String
• articleId — Required — Number

Example:

{
 "id": 1,
 "content": "Hey, this was a nice post!",
 "author": "Alex Martinez",
 "articleId": 1
}

Article (Object)

• id — Required — Number
• title — Required — String
• content — Required — String
• writerId — Required — Number
• categoryId — Number
• comments — Array of Comment
• slug — Required — String

Example:

{
 "id": 1,
 "title": "The Importance of Regular Exercise",
 "content": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed ac est eu mauris faucibus consectetur. Nunc vehicula hendrerit nulla, non vulputate justo ultrices sit amet. Mauris varius lorem sit amet sem laoreet, id lacinia eros auctor. Donec tincidunt augue vel dolor pharetra tincidunt. Aliquam dapibus sed neque vitae sagittis. Sed sit amet nibh id nunc vehicula laoreet. Morbi fermentum auctor est, eu tempor tortor lobortis nec. Etiam tincidunt, lorem a viverra facilisis, nunc lorem aliquet magna, euismod ullamcorper ligula metus et augue.",
 "writerId": 1,
 "categoryId": 1,
 "comments": [
  {
   "id": 1,
   "content": "Hey, this was a nice post!",
   "author": "Alex Martinez",
   "articleId": 1
  }
 ],
 "slug": "importance-of-regular-exercise"
}

Category (Object)

• id — Required — Number
• name — Required — String
• articles — Array of Article

Example:

{
 "id": 1,
 "name": "Mental Health",
 "articles": [
  {
   "id": 1,
   "title": "The Importance of Regular Exercise",
   "content": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed ac est eu mauris faucibus consectetur. Nunc vehicula hendrerit nulla, non vulputate justo ultrices sit amet. Mauris varius lorem sit amet sem laoreet, id lacinia eros auctor. Donec tincidunt augue vel dolor pharetra tincidunt. Aliquam dapibus sed neque vitae sagittis. Sed sit amet nibh id nunc vehicula laoreet. Morbi fermentum auctor est, eu tempor tortor lobortis nec. Etiam tincidunt, lorem a viverra facilisis, nunc lorem aliquet magna, euismod ullamcorper ligula metus et augue.",
   "writerId": 1,
   "categoryId": 1,
   "comments": [
    {
     "id": 1,
     "content": "Hey, this was a nice post!",
     "author": "Alex Martinez",
     "articleId": 1
    }
   ],
   "slug": "importance-of-regular-exercise"
  }
 ]
}

Writer (Object)

• id — Required — Number
• name — Required — String
• bio — Required — String
• articles — Array of Article

Example:

{
 "id": 1,
 "name": "Esmeralda",
 "bio": "20+ years of experience in IT and very smart.",
 "articles": [
  {
   "id": 1,
   "title": "The Importance of Regular Exercise",
   "content": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed ac est eu mauris faucibus consectetur. Nunc vehicula hendrerit nulla, non vulputate justo ultrices sit amet. Mauris varius lorem sit amet sem laoreet, id lacinia eros auctor. Donec tincidunt augue vel dolor pharetra tincidunt. Aliquam dapibus sed neque vitae sagittis. Sed sit amet nibh id nunc vehicula laoreet. Morbi fermentum auctor est, eu tempor tortor lobortis nec. Etiam tincidunt, lorem a viverra facilisis, nunc lorem aliquet magna, euismod ullamcorper ligula metus et augue.",
   "writerId": 1,
   "categoryId": 1,
   "comments": [
    {
     "id": 1,
     "content": "Hey, this was a nice post!",
     "author": "Alex Martinez",
     "articleId": 1
    }
   ],
   "slug": "importance-of-regular-exercise"
  }
 ]
}

Error (Object)

• code — Required — Number
• description — Required — String

Example:

{
 "code": 500,
 "description": "There was an internal error. Nothing on your side tho!"
}

Resources

After creating the data types, we started creating the resources. Unfortunately, we were only able to finish the Articles resource. Your homework is to create the Writers, Categories, and Comments resources.

/articles

- GET (to retrieve the list of articles)
  - Responses:
    - 200 - OK
      - Body:
        - Media type: application/json
        - Type: Array of Article
    - 404 - Not Found
      - Body:
        - Media type: application/json
        - Type: Error
    - 500 - Internal Server Error
      - Body:
        - Media type: application/json
        - Type: Error

- POST (to create a new article)
  - Responses:
    - 201 - Created
      - Body:
        - Media type: application/json
        - Type: Article
    - 400 - Bad Request
      - Body:
        - Media type: application/json
        - Type: Error
    - 409 - Conflict
      - Body:
        - Media type: application/json
        - Type: Error
    - 500 - Internal Server Error
      - Body:
        - Media type: application/json
        - Type: Error
  - Body:
    - Media type: application/json
    - Type: Object
    - Properties:
      - title - Required - String
      - content - Required - String
      - writerId - Required - Number
      - categoryId - Number
      - slug - Required - String

/articles/{slug}

• URI Parameter Name = slug
• Required = true
• Type = String

- GET (to retrieve one article)
  - Responses:
    - 200 - OK
      - Body:
        - Media type: application/json
        - Type: Article
    - 404 - Not Found
      - Body:
        - Media type: application/json
        - Type: Error
    - 500 - Internal Server Error
      - Body:
        - Media type: application/json
        - Type: Error

- PUT (to update an existing article)
  - Responses:
    - 200 - OK
      - Body:
        - Media type: application/json
        - Type: Article
    - 400 - Bad Request
      - Body:
        - Media type: application/json
        - Type: Error
    - 500 - Internal Server Error
      - Body:
        - Media type: application/json
        - Type: Error
  - Body:
    - Media type: application/json
    - Type: Article

- DELETE (to delete an existing article)
  - Responses:
    - 204 - No Content
    - 404 - Not Found
      - Body:
        - Media type: application/json
        - Type: Error
    - 500 - Internal Server Error
      - Body:
        - Media type: application/json
        - Type: Error

Homework

Before the next session, you have to finish creating the resources in our API Spec for Writers, Categories, and Comments. We just finished the Articles resource in the session.

Recordings

Finally, here are the two recordings you can find about this session.

• The complete video on Twitch
• The edited/clean/shorter version on YouTube

Here you can find the shorter version from YouTube:

And here you can find the complete video from Twitch:

Please let me know if you have any comments, suggestions, or just general feedback for me!

MuleSoft from Start: A Beginner’s Guide — Session 3: Design an API Specification was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last session, we learned about the MuleSoft overview of products. We didn’t do a deep dive into them, but we learned that the main products are

• Anypoint Platform
• Anypoint Studio
• Composer
• MuleSoft RPA
• DataWeave

We also took a look at the community overview like the Ambassadors, Mentors, Meetups, and Help Center.

In this week’s session, we focused on understanding the basics of APIs and learning more about MuleSoft’s API-led connectivity approach. Let’s see a summary of what we learned!

Note: The links and some notes from the session have been added to the GitHub repository for you to follow through with what I’m doing in the video. You can find both recordings (the complete and the shorter one) at the end of the post.

Understanding APIs

Because I had already written a series of blog posts about simplifying your road to learning the basics of APIs, I referenced those posts when explaining them. In the GitHub repo, or here, you can find the links to read them on your own if you still have questions or want some further clarification.

Part 1: What is an API?

The way that I look at APIs is something like the following diagram.

You, as a client consuming the API, don’t really care about how the API is really working. You don’t care about the programming language it’s written in or what tech stack it’s using. You only care about what you can send in and what it returns back.

Whatever you send into the API is a request and whatever it returns back to you is a response. In the request, you send your input data along with the data type and the operation (what you want the API to do with the input data). In the response, you get some output data along with its data type.

Part 2: Analogies and Examples

Restaurant

In this analogy, you are the client. You arrive at this restaurant and take the menu to see the list of available food. You request the server to give you a hamburger. At this point, you don’t know exactly what the server is doing to make sure you get your order right. They may be writing the order down to pass to the kitchen, they may input your order in the computer, or whatever they do — you just care about getting your food exactly how you asked for it. After some time, the server comes back and gives you your order in response to your request.

Calculator

In this analogy, you input two numbers: 2 and 2; and select the addition (+) operation. After you press the equals button, the calculator does its thing and returns 4. Again, you don’t care much about what’s inside the calculator or what it does to give you the result. You just care about getting the correct result.

Human Resources system

First, you send the following request to your HR system with some CSV data. You ask the API to retrieve the listed employees’ first day of employment.

The HR API returns the same CSV information you had previously sent, but now adding a new field called First Day.

In the following picture, we can appreciate the same example, only using a JSON data type instead of a CSV data type.

Part 3: What are HTTP Methods?

There are 9 HTTP methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH. However, the most popular ones are GET, POST, PUT, PATCH, and DELETE.

• GET: Read or retrieve data from the server or the API.
• DELETE: Delete data from the server.
• POST: Create new data. Sending the same information more than once can result in duplicated data.
• PUT: Update or replace existing data. It can also be used to create new data. Sending the same information more than once will have the same effect as sending it just once.
• PATCH: Update or modify parts of existing data.

Whether you’ll be using POST or PUT to create new data is really up to you. These are just Mozilla’s standards. It is recommended that you follow them for the comfort of other developers using your API, but the design decision is really up to you.

Part 4: What is a URI?

If we take this URI as an example: https://official-joke-api.appspot.com/random_joke, we can separate the parts of this URI into the following.

…And that’s all that we need to understand from this post! 😃

Part 5: Intro to Postman and Query Parameters

If you go to the following link: https://www.google.com/search?q=cats, you are basically searching for cats in Google. Notice how there’s a ?q=cats after the path of the URI. This is our query parameter.

Take a look at a more complex example from Expedia which contains more query parameters:

https://www.expedia.com/Hotel-Search?adults=2&d1=2020-11-23&d2=2020-11-24&destination=Toronto%20%28and%20vicinity%29%2C%20Ontario%2C%20Canada&endDate=2020-11-24&regionId=178314&rooms=1&semdtl=&sort=RECOMMENDED&startDate=2020-11-23&theme=&useRewards=false&userIntent

We can put this URI in Postman to see a more human-readable list of all the query parameters we have here.

Part 6: What are HTTP Status Codes?

So far we have been focusing on the request part. Now, let’s see what other data can be returned in the response.

There are a lot of Status Codes reserved for certain API Responses, but we will be looking at the most popular ones: 200, 201, 202, 204, 400, 401, 403, 404, and 500. You can find a complete list here with their definitions.

• All status codes starting with 2 mean that the process was a success. Like 200 OK or 201 Created.
• Status codes starting with 4 mean that there was an issue with your request. Like 400 Bad Request or 404 Not Found.
• Status codes starting with 5 mean that there was an issue from the server side and not with your request. Like 500 Internal Server Error.

And that is all for learning about APIs! Now let’s take a look at what is API-led connectivity in MuleSoft.

What is API-led connectivity?

This is an architectural approach that we tend to do with the APIs we design using MuleSoft. There are three layers to this approach: Experience, Process, and System APIs.

• Experience layer: Top layer. These APIs connect with the client applications like a Mobile app, a Web app, or a Smartwatch app.
• Process layer: Middle layer. These APIs orchestrate the Experience and System layers.
• System layer: Bottom layer. These APIs connect with the server applications or third-party systems like SAP, Facebook, Salesforce, etc.

Recordings

Finally, here are the two recordings you can find about this session.

• The complete video on Twitch
• The edited/clean/shorter version on YouTube

Here you can find the shorter version from YouTube:

And here you can find the complete video from Twitch:

Please let me know if you have any comments, suggestions, or just general feedback for me!

MuleSoft from Start: A Beginner’s Guide — Session 2: What is an API? was originally published in Another Integration Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.