API Best Practices: API Management

February 5 2015

0 comments 0

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

Design is Important, But…

Over the last several weeks we’ve looked at the design aspect of building APIs.  We’ve covered planning out your API, spec driven development, and best practices.  But your API is really a vehicle for developers to access data and services, much like a plane is a vehicle for transporting people to and from places.  But building the plane isn’t enough, along with having the actual vehicle, you need airports with checkpoints to make sure that only the people who are supposed to be getting in that plane have access, and likewise that no one is trying to do anything malicious.

Using .NET code and Visual Studio with Anypoint Platform

February 4 2015

0 comments 0

.NET ConnectorOur January 2015 release of Anypoint Platform brings with it many new updates to power API-led connectivity. For organizations with investments in .NET, we are thrilled to add to the list the 2.0 release of our .NET Connector. The enhanced .NET Connector enables .NET developers to use familiar languages and tools when building integration applications with Anypoint Platform.

With this connector, you can use Visual Studio and any Common Language Runtime (CLR) language to write code for complex transformation and message enrichment to apply business rules or perform custom message routing logic within a Mule application. You can also reference or reuse existing code including third-party assemblies, and build new libraries of custom codes specifically for your application.

Library upgrades in Mule ESB 3.6

February 3 2015

6 comments 0

If you have read the Mule ESB 3.6 release notes then you already know what I’m about to say, but just to recap, here we go…

A lot of effort was put in 3.6 to upgrade our libraries stack. Even though we try to stay innovative, it doesn’t make sense to reinvent the wheel all the time, so we use a lot of third-party libraries. However, keeping those up-to-date while maintaining our strict backwards compatibility policy is something that’s really difficult to do. As a result, we haven’t always managed to keep up.

[email protected]: ProtoNight

February 2 2015

0 comments 0

Welcome to the first episode of [email protected], a new podcast series that highlights some of the coolest meetup groups in the San Francisco area. In this episode, we’re talking about ProtoNight – a meetup where ideas meet developers, FreeCodeCamp.com, Fiskkit, Xiki, and a recap of the 2014 APICon hackathon.

A special thank you to everyone that participated in this inaugural [email protected] podcast!  

API Best Practices: Response Handling

January 30 2015

2 comments 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.

Json validation using a draft v4 schema? Oh Yeah!

January 29 2015

2 comments 0

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!

Polyglot programming in Mule: Scripting pack now part of the distribution

January 28 2015

0 comments 0

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!

Developer Spotlight: Chocolabs

January 27 2015

0 comments 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

Achieving Digital Transformation Nirvana in Financial Services

January 26 2015

0 comments 0

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.

You’re into XML? Mule now supports XPath, XSLT and XQuery 3.0

January 22 2015

3 comments 0

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.