Tag: REST

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.

Mike Stowe on Thursday, January 15, 2015

API Best Practices: Hypermedia (Part 3)

0

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

Or jump to part one of the hypermedia sub-series.

A Road Trip

First off, let me apologize for the delay in this third part of the hypermedia sub-series. Christmas meant a warm trip back to Minnesota, a road trip through the Texas panhandle, and numerous snow storms in between — until finally I had the chance to cut through the mountainous desert of Southern California on my way back to beautiful San Francisco.

Now I understand some of you are probably wondering what any of that has to do with this post, other than it’s about 3 weeks after promised. One of the greatest challenges of the drive was battling my way through the snow and construction, and just hoping that the interstate would stay open (they literally close the interstates if it’s bad enough). But the one thing I could be sure of was that at every turn, between my steady GPS and road signs, I knew where I was going, and I knew when my path was being detoured or I couldn’t take a certain road… I knew this, because everything was nice and uniform.

Norberto Herz on Friday, January 9, 2015

Let’s honor the future

0

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. Come on? FAXES!

Mike Stowe on Thursday, December 18, 2014

API Best Practices: Hypermedia (Part 2)

0

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

Or jump to part one of the hypermedia sub-series.

The Harsh Reality of the State of Hypermedia Specs

Hypermedia sounds great in theory, but theory only goes so far. Where hypermedia really shines, or completely fails, is in implementation. Unfortunately, as hypermedia is still a relatively new aspect of web based APIs, there isn’t one specified way of doing things. In fact, you’ll find that even some of the most popular APIs operate completely differently from each other.

Mike Stowe on Thursday, December 11, 2014

API Best Practices: Hypermedia (Part 1)

3

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

What is Hypermedia

One of the challenges to implementing and correctly using hypermedia in your REST API is first understanding what hypermedia is, and what it means to use hypermedia as the engine of application state (HATEOAS).

Part three of the API design best practices .

Once you have an understanding of what your API needs to be able to do in order to meet your developer’s requirements, it’s important to ensure that it remains as flexible and extendable as possible.  Taking advantage of best practices not only means that your API will be familiar to developers, but also ensure that it remains fluid enough to extend and build on top of it in the future.  Here are this week’s best practices to help keep your API agile:

Mike Stowe on Thursday, November 13, 2014

API Best Practices: Plan Your API

0

Part One of the API design best practices series.

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:

MuleSoft has teamed up with DayCamp4Developers to put together one full day of API talks by today’s thought leaders. Best of all, this event takes place online. That means anyone with a browser can attend, and it’s FREE!

You’re not going to want to miss this exciting event where our speakers will be talking about the API landscape, building and designing your API, and ensuring that developers use it. So mark your calendars and join us on November 7th for this very special edition of DayCamp4Developers sponsored by MuleSoft.

Get your FREE ticket »

Nial Darbey on Thursday, August 28, 2014

SOA School: Put your SOAP to REST

0

The benefits of applying the principles of SOA when catering to the IT needs of your organization are clear in a business-driven, vendor-neutral architecture. It considers all requirements from the perspective of the business process and delivers implementations in order to automate the same. The implementations themselves, driven by the same SOA principles and goals, are not bound to any one particular vendor because they are intrinsically interoperable, that is, they expose and consume Services or APIs (we use the terms interchangeably here).

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!

So you can use the UI to manage all your geographically distributed instances, but what about automation?

Yes UI is good, but…