Today, in the age of APIs, an API is not just a technical interface on top of a database. On the contrary, your API is your new business model. In the past, APIs were seen as just tools for Developers. But nowadays, their scope is not limited to internal use. The companies who make APIs are now exposing them APIs to external users around the globe. For example, Google Maps' APIs use Uber's APIs to calculate fares and travel times to destinations. 

We've all been excitedly waiting for the new version of Mule 4 that Mulesoft will be releasing soon. Here are some important features we want to highlight that will be available in Mule 4:

These questions can pop up in any Web project and must be clarified before the initial implementation. Let's start by understanding the concepts of REST and SOAP and draw comparisons about their differences. 

One of the biggest challenges in system development is choosing an Architecture for the system. There is not any predefined architecture that can be applied directly to your projects. In this article I would like to discuss a simple Mule deployment architecture.

Mule has the concept of a Domain Project to share common resources. However, per the documentation, there are some limitations when using a Domain Project to share resources. Here are the main limitations as per the documentation:

This is the second part of my previous post on Encryption using Mule. In the previous post in the JCE Encrypter configuration, I did not use Keystore. This week, I will create a Keystore and use it for encryption.

“Do not reinvent the wheel.” That’s the principle Mule applies when it comes to Mule Message Security. Anypoint Enterprise Security is a suite that comes bundled with all the necessary modules/methods for applying security to Mule Service Oriented Architecture (SOA) implementations and Web services.