This post is brought to you by Pablo Cibraro. Pablo is a Software Architect focused on MuleSoft’s solutions for Microsoft.
As part of our on-going effort to make Anypoint Platform even more accessible and intuitive for .NET developers, we are thrilled to introduce a RAML parser and Visual Studio extensions that make it easy to consume and implement APIs using RAML.
What is RAML?
RESTful API Modeling Language (RAML) is a language for describing a Web API in terms of resources, methods and implemented patterns (security, paging, filtering, projections, etc). RAML is based on YAML and leverages other open standards such as JSON or XML to document the schema of the resource representations. In short, RAML allows you to do the following for your API:
- Write Human-readable documentation using Markdown
- Define supported resources and HTTP methods
- Reuse common usage patterns such as data paging or filtering
- Describe expected responses for multiple media types with schemas and examples for each
- Define security aspects
Here’s an example of a RAML document describing a very simple API for browsing a movie catalog:
Join us in the next installment in the MuleSoft webinar series as we talk about how to becoming a mobile enterprise.
Once a supplementary channel for the enterprise, mobile is now quickly becoming the primary channel for delivering business critical information and experiences to partners, customers and employees. Join Sarvesh Jagannivas, VP of Product Marketing at MuleSoft, and Uri Sarid, CTO at MuleSoft in, “The Path to Becoming a Mobile Enterprise” as they discuss the mobile enterprise opportunity and the biggest challenges preventing enterprise from a successful mobile delivery.
Together with the release of Mule 3.6, we’ve also shipped a new Mule agent that exposes new APIs to manage and monitor running Mule, enhancing the experience of creating API-led connectivity in a big way.
The new Mule agent exposes APIs that allow enterprises to easily tie in to their existing SDLC processes and applications. The agent also has a flexible framework that’s quickly customizable to meet new operational governance requirements around Mule.
This is the first of a series of blog posts where you can learn about this new agent.
What is the new agent?
The agent provides two very powerful pieces of functionality. Specifically:
- the Mule agent exposes Mule runtime APIs via REST and/or Websockets
- the Mule agent enables Mule instances to publish data to external systems
Let’s talk about these two pieces of functionality more, as these impact the way users interact with Mule ESB from an operations, manageability, and monitoring perspective.
The first thing that comes to mind on Mule Cache scope is how to implement this cache mechanism with a webservice. Mule has a wonderful mechanism of caching with its cache scope, available in Anypoint Studio with Mule ESB Enterprise, and there are examples available on internet on how to extend the Mule caching mechanism with EHCache. Check out Mule caching with EHCache if you are still looking for an example.
The January 2015 release of CloudHub features several key upgrades to our infrastructure. With this release, customers will be able to run more applications per vCore (10 per vCore – up from the current limit of 4), and will also be able to run more compute and memory intensive applications – which consume up to 4 vCores in one instance. We are also releasing a new security feature – data encryption for persistent queues, which will help customers with their security and compliance needs.
More Applications per vCore, and Support for Bigger Applications
Starting with the January 2015 release, customer applications running on CloudHub will have a bigger palette of worker sizes to choose from. Currently, a customer application has a choice of 3 worker sizes – Shared, Regular, or Double, representing 1/4th of a vCore, 1 vCore, and 2 vCore capacities respectively. Starting February 7, applications running on CloudHub will have 5 different worker sizes to choose from, with the compute and memory capacities described in the following table:
|New Worker Sizes
||500 MB Mem
||1 GB Mem
||1.5 GB Mem
||3.5 GB Mem
||7.5 GB Mem
Part six of the API design best practices series. 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.
Our 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.
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.
Welcome to the first episode of Meetups@MuleSoft, 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 Meetups@MuleSoft podcast!
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.