I am excited to announce that our November release of the Anypoint Platform for APIs is now live. This update to the platform includes a variety of new features and workflow enhancements aimed at streamlining the process of managing APIs. These new features include the following:

  • Improved proxy configuration & support for HTTPS and load balancer scenarios
  • API version deprecation
  • Swagger file import & folder support in API Designer
  • Analytic tracking of policy violations

Proxy Configuration Improvements

As part of the November release of the Anypoint Platform for APIs we have also released a new version of the API Gateway, version 1.3 which you can download here. The new API Gateway includes enhancements that now make it possible to easily deploy API proxies in a loadbalancer environment as well as use a shared port for HTTP and HTTPS endpoint. Shared ports allow you to deploy multiple API proxies to a single gateway. As a result, we’ve modified the proxy generation interface in the platform. Please note, that to take advantage of these new updates to the API proxies you will need to use the latest API Gateway version 1.3. To learn more about configuring and deploying proxies in the Anypoint Platform for APIs you can find full documentation here.

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

Define Your API in a Flexible, but Standard Spec

I cannot stress the importance of spec driven development enough.  One of the quickest ways to kill your API is to define the API in your code, instead of coding to its definition.  By utilizing an API modeling spec such as RAML you can quickly build out your API in a consistent manner using code and pattern reuse.

Utilizing pattern design and code reuse helps to ensure that your API remains uniform across the full interface, keeping resources and methods alike standardized and easily implemented by your developers.

Enterprise integration poses huge challenges for developers, and with so many tools and solutions to choose from, finding the right one can be tricky. DZone’s 2014 Guide to Enterprise Integration, their latest research and guide, provides coverage of the enterprise integration landspace and offers key insights from 500+ developers and experts. The guide considers web services, integration architecture, SOA governance, enterprise service bus products, message queues, integration frameworks and suites, iPaaS solutions, API management platforms and much more.

Topics covered in the guide include:

  • Architecture: How We Got Here
  • Integrating Microservices Into The Enterprise
  • Decomposition Patterns for Monolithic Applications
  • The Future of Developing and Integrating Applications
  • Microservices: Taking a Closer Look
  • A checklist for “The API Maturity Model”
  • Beyond Traditional Enterprise Integration: Bi-Modal IT

Digital TransformationIn a recent MuleSoft webinar, Top 5 Steps to Drive Your Digital Transformation Initiative, Ray Wang, Principal Analyst & CEO at Constellation, stated “A digital divide exists between the organizations who have built digital business models and everyone else”.  These digital business models are often fluid, meaning IT must adapt quickly to meet changing business demands.  For 63% of senior executives running initiatives, however, IT isn’t moving quickly enough.

was designed to address this need for IT speed.  That’s why MuleSoft customers are able to move 2-5x faster when developing services, integrating applications, and designing new products after adopting our solutions.

In this 30 minute , Tyrone Borromeo, MuleSoft Solutions Consulting Lead, will cover the broad set of capabilities available out-of-the-box with Anypoint Platform.  He will also highlight best practices for configuring flows, applications, and servers to quickly deliver business agility across a broad set of integration use cases.

Mike Stowe on Thursday, November 13, 2014

API Best Practices: Plan Your API


Part One of the API design best practices .

Understand WHY you are building an API

Perhaps the foundation of the foundation, understanding why you are building an API is a crucial step towards understanding what data/ methods your API should make accessible and how your users will utilize it. Unfortunately, API is a buzzword right now, and many companies are rushing to build APIs with the idea that “we’re going to make our data accessible and our users will love it!” There’s probably some truth to that, but that is not a good enough reason. What exactly are you making accessible and why? Who are your API users – are they your customers, or third party services, or developers who are looking to extend upon your application for their customers? Understanding the market you are serving is vital to the success of any product or service.

Key questions to ask:

If you’re striving to make your business more mobile, social and agile, you’ll want to look into the latest offerings from MuleSoft and Salesforce.

1 Lightning enables rapid development of applications that can transform how businesses engage with employees and customers. Maximizing the potential of these applications requires the ability to connect with data across the enterprise in way that is secure and scalable, but also agile. Anypoint Data Gateway from MuleSoft supports and extends 1 Lightning Connect to more easily enable access to data stuck in back office systems.

Mike Stowe on Thursday, November 6, 2014

New Series: API Design Best Practices


By now, you’ve probably already seen the image of the iceberg cross section showing just how many APIs are available out in the world. With over 13,000 public APIs available for use across the web, and hundreds of thousands more being used privately and in-house, the possibilities are endless.

The demand for flexibility and extensibility has driven the development of APIs and tools alike, and in many regards it has never been easier to create an API than it is today with multitudes of frameworks (such as JAX-RS, Apigility, Django REST Framework, Grape), specs (RAML, Swagger, API Blueprint, IO Docs), and tools (API Designer, API Science, APImatic) available.

However, despite the predictability of the demand for APIs, this tidal wave has taken many by surprise. And while many of these tools are designed to encourage best practices, API design seems to be constantly overlooked for development efficiency. The problem is, however, that while this lack of focus on best practices provides for a rapid development framework, it is nothing more than building a house without a solid foundation. No matter how quickly you build the house, or how nice it looks, without a solid foundation it is just a matter of time before the house crumbles to the ground, costing you more time, energy, and resources then it would have to simply build it right the first time.

Your customers, competitors, and suppliers are becoming digital. If you joined us for Ross Mason’s webinar, Connect Faster to Drive Value: A Strategy for Rapid IT, you’ll understand why you must digitally transform your own business. Now how do you cut through the hype and get started?

We’ll tell you in the next webinar in the Connected Company : Top 5 Steps to Drive Your Digital Transformation Initiative. In this webinar, R ‘Ray’ Wang, Constellation Research, will discuss five simple steps market leaders are taking to lay a foundation for and highlight a MuleSoft customer who has successfully taken these steps to accelerate IT’s ability to deliver business value.
Ray Wang

Walk away from this webinar with:

  • Questions to ask to identify your preparedness for digital transformation
  • IT innovations that are driving business model disruption
  • Tips to build collaboration between IT and business to drive faster results

Presenter: R “Ray” Wang, Principal Analyst, Constellation Research

If you’ve ever worked on performance issues with an IO- intensive app, there is a good chance you already know that the application performance degrades when the disks are stressed out. This fact is usually well known, but the reasons behind it aren’t always clear. I’d like to try and clarify what’s going on behind the scenes.

In a typical scenario, when data is written to a file, it is first written to a memory area reserved as the page cache. The page holding the newly written data is considered dirty. After a period of time per the kernel IO policy, the kernel flushes the dirty data to the device queue to persist to hard disk. Once the data gets to the queue, the rest is mechanical: The device driver reads the IO requests, then spins, seeks and writes to the physical disk block where the file is. The journal file is written first if enabled, then the actual file.

In a recent discussion with a few other engineers, an idea of disabling file system journaling came up to improve disk write latency. While this is certainly true because it is one less disk operation per write, the actual time gained is negligible because the journal file is in the same block as the file to be written. The benefits of having the journal file to restore the disk from a crash far outweighs the little latency saved.

Thanks to those of you who attended our webinar last week, “The API Love Triangle: Delivering Successful API Programs,” and we hope that you found the session valuable. Now you know that the API love triangle is composed of three key people and that the success of your API program depends on satisfying the needs of each:

  • The API Developer, who’s always looking for ways to be more efficient, to get their APIs to market faster, to re-use existing artifacts rather than re-creating things from scratch.

  • The Application Developer, who wants to know which APIs are available for use and when they find one that fits their project, how can they get started with it quickly?

  • The IT Leader, who wants to make sure that the APIs their team releases are properly secured and managed and that developers use those APIs instead of creating their own.