0

Part five of the API design best practices series. Read part one: Plan Your API.

Provide Helpful Responses

Building a solid foundation to ensure the scalability and longevity of your API is crucial, but just as crucial is ensuring that developers can understand your API, and trust it to respond with the appropriate header codes and error messages.

In this week’s API best practices, we’re going to cover how to ensure that developers understand exactly what happened with their API call by using the appropriate HTTP Status Codes (something that is often times missed), as well as by returning descriptive error messages on failure.

Sometimes you’re expecting a JSON, specially when publishing or consuming a REST API. But you need to make sure it’s a good JSON, not the kind of JSON that would kill you with a machete. Since the Javascript Object Notation format (JSON for short) can be used to described pretty much anything, validating that the one you received actually complies with what you expected is no simple task. Or at least it wasn’t until the JSON schema specification came out. Just like XSD schemas are XML documents used to describe how a valid XML looks like, a JSON schema is a JSON document used to make sure that yours doesn’t come with a machete. You gotta love the recursion of it!

Sometimes when transforming complex data structures or applying business rules to your integration, you may face the need to add some custom code. We make our best effort to try to productize and solve every common use case we come across, but sometimes it’s just not enough. When that happens, you probably turn to the programming language you love the most for help. If you’re a Java guy, you can build your own custom components and/or transformers inside Mule. If you’re into .NET, we recently released our .NET integration framework. We also have something we call the “scripting pack” which enables the use of scripting languages such as Groovy, Javascript, Python or Ruby inside your flows. For Mule 3.6, we decided to give it a big upgrade!

Indy Sen on Tuesday, January 27, 2015

Developer Spotlight: Chocolabs

0

To app your life, CHOCOLABS takes an API-first approach

CHOCOLABS is one of the largest app publishers in Taiwan with over 50 iOS/Android entertainment focused apps under their belt. We recently spoke with Jerry Weng, one of their co-founders, to talk about building a team, finding a niche, and driving business growth with the right development tools.
Q – Indy | A – Jerry

Q: Who is CHOCOLABS?
A: We are an app publishing company led by three co-founders who met as interns at Microsoft Taiwan. It’s a long story, but we were all in different years, and had different backgrounds—for example Kevin and I both did computer science, whereas our CEO, David, got his masters in business management and worked at a global marketing research firm before we met and decided to form the company.

Financial services information technology (IT) has transformed from order taker to strategic business partner. As part of this transformation, IT organizations are finding they must address key challenges with legacy modernization, data management and digital transformation.

MuleSoft has launched a three-part white paper series discussing these challenges and how financial institutions are overcoming them. In the first installment in our Connected Financial Institution white paper series, we discussed how aging back office systems, operational effectiveness and open source adoption are driving legacy modernization initiatives across the financial services industry. The second installment in the series discusses key data management challenges facing firms including an ever-evolving regulatory compliance landscape, deepening customer relationships with a 360-degree view, and improving data driven decision making.

In spite of JSON’s reign as the king of API data format, XML still remains the exchange data format of choice for a number of systems. Any service exposing functionality through SOAP, and many application built years ago (or even nowadays) still depend on XML to share data – to such an extent that in April 2013 the W3C published a new spec for version 3.0 of the XPath, XSLT and XQuery standards. We decided it was time to update the platform’s support for these standards and fix a couple of things while at it.

Mariano Gonzalez on Wednesday, January 21, 2015

Give your old school API some love

2

If you’re an assiduous reader of this blog, then you probably already heard about our vision around APIs, our Anypoint API Manager solution and all our RAML based stories. Those are our recommended way of approaching REST APIs and if you haven’t already, we all highly recommend you to take a look at them. However, we’re about connecting everything, everywhere. Thus we recognize that there are a lot of APIs out there built in plain old Java code and a migration process is not something you can do overnight. If you own such an API, this post is about us wanting to help you too. Anypoint Platform includes a Jersey module to allow embedding Jersey-based APIs into the runtime, reusing the Java code powering your API but still gaining access to all the other features of the platform. In Mule 3.6 we upgraded our supported Jersey version from 1.6 to v2.11 to give you access to the latest and greatest that Jersey has to offer.

victor.romero on Tuesday, January 20, 2015

Become an Integration Hero

0

MuleSoft got its start years ago with a great open source project, Mule ESB.

Today we continue to be big believers of open development and that’s why every single line of the community edition source code is publicly available on GitHub.

We leverage many open source technologies everywhere within Anypoint Platform, from the core integration engine, Mule ESB; to hundreds of connectors, tooling, and plugins of all kinds.

Mariano Gonzalez on Tuesday, January 20, 2015

Asynchronous Logging in Mule 3.6

8

“Logs are like car insurance. Nobody wants to pay for it, but when something goes wrong everyone wants the best available” - Pablo Kraan

The phrase above fully explains why logs are important and why we need to be able to log as much information as possible without impacting performance. Because logging usually implies an I/O operation, it’s a naturally slow operation.

The Problem

Before Mule 3.6, logging operations were done using synchronous I/O. This means that the thread processing your message has to wait for the log message to be fully handled before it can continue.

As part of our API-led Anypoint Platform January 2015 launch, I’m pleased to announce the next version of our runtime and tooling, Mule ESB 3.6 and Anypoint Studio January 2015. This release helps users more quickly connect to and design APIs based on a new HTTP connector that adopts a design-first and resource-based approach, all with higher performance. The new release of Anypoint Studio also improves the design experience, upgrades the base Eclipse runtime, and connects to Anypoint Exchange, our expansive library for connector and example information. Finally, major updates to AMQP and our SDLC tooling have been released.