TIBCO Mashery API Developer Blog

Support for Call Requested Error Formats

We were working with another client recently and found that we had a little weakness around how we provide error message responses back to calling apps for some protocols.  As you may know, our API Proxy Service handles a number of your business rules like rate limits, throttling, security and so on.  When one of these rules fail, or there is generally a technical problem with the call, we respond immediately back to the caller with some type of error response.  And we've always allowed you to customize the error responses to meet your needs. 

As is pretty common in REST APIs, in order to make development a bit easier, many will allow the developer to request a preferred response format.  So if you like looking at XML more than JSON, for many APIs, add a parameter or some indicator of some kind to the call (e.g. "?output=JSON" or "/method.xml") and you get your responses in the format you wish.  Good stuff, but we found a little problem in our app.  The custom error formatting feature only allowed you to serve up one.  So we could respond with JSON, but not XML for example.  So while you were responding with JSON, every once in a while when they got an error, they'd get Mashery XML.  We fixed that today.

Now, you can define what we call an "Error Set".  You can then define the logic for picking the Error Set to respond with based on attributes of the call.  Simple little feature, but one that makes your developer's experience much tighter.  Have a look and contact us at support@mashery.com if you have any questions.

Step 1: Define your Error Sets.  The Error Set Name should be a value that your developers will use in their call.

Step 2: Configure your endpoint. Select the Default Error Set for cases where the developer doesn't ask for something specific.  Then set the Selection Logic for picking the error format that your developer may request.  If your accepting params in the GET or POST of a call, enter the param name.  If you are using a resource type, such as api.mashery.com/search.xml, select the "Resource Type" selection logic and no value is necessary in the Selection Location field.