Cloud Blog

Multiple endpoints per API

Dynamic Endpoint functionality of API Cloud allows you to dynamically pick the backend to which each call is routed based on the call’s properties.

For example, suppose you have an API that has two resources /countries and /regions:

And suppose the actual implementation of the functionality is at two different backends. /countries is implemented by first.backend.url and /regions by something.different.url.

Fear not, this is fairly easy to implement with API Cloud. You simply need to select Dynamic Endpoint as the Endpoint Type and upload the In Flow sequence that defines the rules to route the traffic:

In our sample scenario, the In Flow sequence might look similar to this:

<sequence name=”dynamic_ep” trace=”disable” xmlns=”http://ws.apache.org/ns/synapse“>
    <switch source=”get-property(‘To’)”>
        <case regex=”.*/countries/.*”>
            <property name=”service_ep” value=”https//first.backend.url“/>
        </case>
        <case regex=”.*/regions/.*”>
            <property name=”service_ep” value=”https://something.different.url“/>
        </case>
        <!– add endpoints as needed –>
        <default>
            <property name=”service_ep” value=”http://some.default.url”/>
            <!–default endpoint if required. However there should be a matching resource–>
        </default>
    </switch>
    <header name=”To” expression=”get-property(‘service_ep’)”></header>
    <property expression=”get-property(‘service_ep’)” name=”ENDPOINT_ADDRESS”></property>
    <!–Please note that “ENDPOINT_ADDRESS” (additional) property is defined here in order to populate
    destination address for statistics (API Usage by Destination). –>
</sequence>

You can obviously define more complex rules if needed.

Do you have multiple backend services that need to become a single API? Dynamic Endpoints can get you going!

 

Now with WebSockets

WSO2 API Cloud now fully supports publishing WebSocket APIs. WebSocket is a TCP-based protocol that is a part of the HTML5 specification, enables full-duplex communications and streaming, and reduces network traffic and delays.

In API Cloud, you can now treat WebSockets just the same way as you treat regular HTTP protocols. It is just another option when you add a new API:

The wizard then guides you through the rest of the process so you can define your policies and make the WebSocket endpoint fully managed.

If you need details, just read this API Manager tutorial that covers the functionality: Create a WebSocket API – now this page applies to API Cloud as well.

Custom API error messages

When API subscribers make mistakes during API invocation be it a wrong REST path, submitting an invalid OAuth key or going beyond the throttling limit – they get an error message like:

{“fault”:{“code”:900902,”message”:”Missing Credentials”,”description”:”Required OAuth credentials not provided. Make sure your API invocation call has a header: \”Authorization: Bearer ACCESS_TOKEN\””}}

We now allow WSO2 API Cloud customers to change these messages so you can have something like:

{
 “errors” {
“status”:900902,
“message”: “Make sure to pass OAuth key as Authorization Bearer. Confused? Read our documentation and samples at our.wonderful.dev.portal”
     }
}

 

Custom messages work for both JSON and XML responses.

Making the change is easy: submit a ticket via API Cloud‘s Support menu, let us know which messages you want to be changed, and our engineers will get your custom messages into the system.

This nicely affects other branding options that we have such as custom URL, custom developer portal theme, and custom emails.

Categories

Recent Posts

Most Popular Posts