For close to twenty years, the “common standard” of APIs on the web has been summed up in one word: “RESTful.” Designers, developers, and software architects have promoted, debated, and derided the notion of RESTful APIs in successive waves over the years with all sorts of pundits declaring REST “dead” and offering some other current practice as “the new REST” or, even better, “the REST killer.” Probably my favorite rejoinder in this space is Matt McLarty’s “
When I was growing up, I loved playing the classic 1993 game DOOM. This is why recently, as part of a talk I gave at APIs and IPAs, I decided to do a demo of how I embedded a RESTful API into DOOM, allowing the game to be queried and controlled using HTTP and JSON.
I wrote the entire API specification for the project in RAML––a RESTful API Modeling Language based on YAML that allows you to create standardized,
The vast majority of RESTful APIs follow a simple “request-response” message exchange pattern, but that pattern is often too limiting and is not sufficient to achieving robust and reliable application performance. We frequently get questions from customers asking: ‘How I design asynchronous APIs?’ and ‘How I design an API that allows for the concurrent modification of the same API resource without bringing the resource into inconsistent state?’. In this blog post, we present two approaches answering these questions using standard HTTP headers and status codes.
When you’re designing an API, it’s important to know the type of API you want for your specific project and what it’s advantages and disadvantages are. REST, or RESTful APIs are some of the most popular APIs; but how do you know that this type of API is right for what you want to do?
RESTful APIs are designed to take advantage of existing protocols.
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.
This post is about fulfilling some expectations created by sci-fi movies, using Arduino and Nobel to expose RESTFul APIs for controlling physical devices.
The early-arriving future disappointment
This is the year that, according to some Hollywood prophets, cars will be finally flying, clothes will adjust their sizes to our bodies, trash will be combustible, and houses will be intelligent – though I never understood why they thought that an intelligent house would have a fax hanging on the wall.
One of the greatest challenges API developers face is creating an API that is flexible enough to pass the tests of time and technology. In other words, creating an API that is built to last. Here are some tips to help you ensure your API has a happy, and long life expectancy – saving you a lot of frustration, and your company a lot of money!
When building Mule architectures a company will often need to run several instances of Mule ESB: Some on QA, some on staging, and on production, perhaps some instances running locally and some others in another continent. Managing Clusters of Mule Servers, keeping track of what application is running where, and knowing what is the health of those instances at a glance, or even being warned when something wrong happens… That is Mule Enterprise Console job!
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.