Tag: REST

Mike Stowe on Thursday, December 18, 2014

API Best Practices: Hypermedia (Part 2)

0

Part four of the API design best practices . 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 really shines, or completely fails, is in implementation. Unfortunately, as 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 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 .

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…

To fight XSS attacks, the web browser imposes the same origin policy for requests made by JavaScript code:

But there are a lot of use cases where this kind of cross domain HTTP request is desired, so developers came up with some workarounds:

  • Server side proxy: the idea is to avoid cross domain requests in the browser by doing them on the server:To do that in Mule you can use the HTTP proxy pattern as explained in this post.

We put a lot of effort in to improve error handling in Mule ESB. One of the most common requirements during error handling was the ability to continue processing the same message that was being processed at the time of the exception. And that’s why that is the default behavior for the new exception strategies shipped with Mule 3.3.

Another very common use case was the need to differentiate between handled and unhandled exceptions within a flow. In this case we are going to focus on handled exception and the new catch exception strategy.

In this blog post I will show extend Mule in a simple way using the recently released Mule DevKit. The goal of the Mule is to accelerate the development of Mule extensions by abstracting you from Mule specific stuff so that you just focus on what your are trying to build.

My idea here is to create a simple Connector to interact with Google Maps API but the concepts covered here can be used in other scenarios as well. Since the Mule DevKit is intended for developers, expect many code snippets so that you can go through this example on your own and play around with the code. You can get the full source code here.