Friday, July 27, 2012

Two jobs requiring Vordel skills in Pleasanton CA

Vordel ninjas who read this blog may be interested in these two jobs posted this week. Both are in Pleasanton, California, and both mention Vordel skills. One is on the security side, the other on the Web 2.0 architecture side:


Thursday, July 26, 2012

Meet the engineers

Check out this video of Paraic from our Engineering team talking about working for Vordel in Dublin:

Wednesday, July 25, 2012

Analytics is now product not byproduct

One trend I've noticed for a long time now is that when customers deploy APIs, it is the analytics and monitoring of those APIs which takes priority on a day-to-day basis. Obviously security, transformation (REST to legacy SOAP particularly), and acceleration are important, and are configured when the API Server is deployed. But if you analyse how API providers spend their time, on a day-to-day basis, the analysis of API Analytics is top. API Analytics feed into monetization strategy, and also provide answers to the "Goldilocks" questions ("Who's been using my APIs?"). They also allow you to see how your APIs are used (from which apps? More via iPhone or Android? At what time of day?). Analytics also feeds into version management ("How many apps have moved on to v2 of the API?"). 

Vordel's API Analytics is part of our API ServerLike Google Analytics, it provides both emailed reports (the top screenshot below) and Web-based reports (the bottom screenshot) which you can drill into, pivot, and save. 

Analytics of your API is absolutely key. As James Governor of Redmonk tweeted, "software is increasingly a disposable asset designed to collect data". It's this data, the analytics of your APIs, which is key.

Tuesday, July 24, 2012

Useful list of Top 100 (well, 25 actually) UNIX commands

Over at , Daniel Redfern has written a list of 25 useful UNIX commands. I note the Vordel product placement in some of the commands :-) . Daniel has deployed Vordel for a large healthcare company here in Boston and also deployed OAuth with Vordel technology recently also. If you have issues with pesky EOL characters in files being passed to OAuth services using the Vordel SR (Service Request) utility, Daniel is your man.

Monday, July 23, 2012

Vordel partners with Redcore for API delivery in Australia and NZ

Australia and New Zealand are often noted for being early adopters of new technologies, and in the API Economy they are no different. Vordel already has a strong customer base in this part of the world, and to build on this momentum we are partnering with Redcore who are experts in Vordel and also in complementary technologies such as Oracle and CA.

In addition, we'll be exhibiting at Gartner AADI in Sydney next month, and running an API workshop during the same week. See you down under next month!

Pro tip: Configuring Load-Balancing using a Remote Host on the Vordel API Server

Did you know you can use the Vordel API Server for downstream load-balancing? You can, and it's easy to setup. Here is how you do it:

Configure a "Remote Host" in Policy Studio with the hostname and port of the load-balanced host you're routing to. Tip: I usually make this into an obvious name like "LoadBalancedHost so that I don't confuse it with an actual real host machine.

Then, under the "Addresses and Load Balancing" tab, configure the addresses (IP Addresses or hostnames) you want the traffic to route to. In this case, I am saying to the API Server "Whenever you are asked to route to 'AppServer' on Port 80, load-balance the traffic over the machines and".

Now, the load-balancing rule will kick in whenever the API Server attempts to route to "AppServer" on port  80. For example, it would apply in the case of the Dynamic Routing scenario I describe in this blog post. 

Note that although the Remote Host entry comes under "Listeners" in Policy Studio, this does not mean the API Server is listening on the hostname of the destination Remote Host, or on its port. A Remote Host is exactly what it sounds like: It's a host "remote" from the API Server itself, which the API Server routes to. Think of it like a hosts file entry. 

Job posting: Senior Java Developer with Vordel skills in the City of London

The basics: Forwarding REST requests with dynamic routing at the Vordel API Gateway

[ Update: Axway acquired Vordel in 2012 and the new name for the Vordel Gateway is the Axway API Gateway ]

A common basic requirement with the Vordel API Gateway is to simply forward REST API requests on to an application server. Now, you can do this on an API-by-API basis using the API Service Manager, as shown in the screenshot below.

But what if you want to simply map all request on to a back-end application server? You can do this with the following simple steps, configured in Policy Studio:

1) Create a policy called (let's say) "Forward REST Request". Drag in a "Static Router" filter first, then right-click on it and choose "Set as start". In this filter, configure the name of the server you want to route your REST requests to. 

You can see below that I've configured it with the machine name "AppServer" and the port "8080". If your machine is called "", this is where you'd configure that.

I follow my "Static Router" filter with a "Connection" filter, which is what actually makes the connection to the back-end REST service. 

Side point: The name "Static Router" is perhaps misleading here, because what it does is allow you to *dynamically* route all requests to the back end machine. If a requests comes in to http://APIServer/foo then it will be routed to http://AppServer:8080/foo , and if a request comes in to http://APIServer/bar then it will be routed to http://AppServer:8080/bar . The API Server does not need to know anything in advance about "/foo" or "/bar".

2) Next, I map my path "/" to the policy I just created. This means that all requests which come through the API Gateway are forwarded to the AppServer machine you've configured. 

Common questions: 

- "Do I need to configure a Remote Host for the machine I'm routing to?". Answer: No. You only need to configure a Remote Host if you are doing something special on your connection to the target server, such as (a) connecting over HTTP 1.0 instead of HTTP 1.1, (b) Monitoring it in Analytics, or (c) Load-balancing the connection over a number of back-end machines (e.g. if you wanted the "AppServer" machine traffic to be spread over two IP addresses). 

- "Will this work for both REST requests and SOAP also?". Answer: Yes. If a SOAP request comes in on a HTTP POST, then the API Server will forward this on to the target machine (in this case "AppServer" on port 8080) over HTTP POST also. 

- "What does ${env.PORT.TRAFFIC} and Address * mean on the listener under Default Services?". This means that the API Server is listening on a port which is configured as an environmental variable, read from the envSettings.props file. In this case, the value is 8080, which means it is listening on port 8080. Address "*" means that the API Gateway is listening on all IP addresses assigned to the machine it is on. If you want to limit it to listening on only one address, this is where you would configure that address. 

- "What is the 'Dynamic Router' filter for then?". It is for configuring the API Gateway to act as a HTTP proxy. 

- "What about the 'Connect to URL filter'?". That is for connecting to a specific path at the destination. For example, if you wanted requests to always be forwarded to http://appserver:8080/foo no matter what path they came into the API Gateway on, this is the filter you'd use. 

- "What if I want to load-balance the traffic to the target REST service on the app server?". To do that, you'd use a Remote Host entry for load-balancing, as described in this blog post

- "How do I test this?". You can use the free SOAPbox testing tool from Vordel to create a REST request to send to the API Server. Just make sure that you choose the verb "GET" if it's a HTTP GET request, under "Request Settings" (which you can get to by clicking on the little down-arrow beside the green arrow button on the toolbar). Also, you may need to set the Content-type header correctly under "Headers", to match what your app server expects (e.g. "Application/json" or "application/x-www-form-urlencoded; charset=UTF-8"). Give your REST request a name (in this case I call it "JSON") and configure the URL of the API Server you are routing to. 

Tuesday, July 17, 2012

Pro Tip: Configuring on-the-wire compression at the Vordel API Server

On-the-wire compression is a simple way to speed up your API request traffic. Especially in a mobile app environment, it is important to keep API latency low. To enable compression/decompression of API requests on the wire to the Vordel API Server, you configure this at the Listener level. Right-click on a listener in Policy Studio (in the screenshot below I'm clicking on Port 80). Click "Edit" then "Advanced" and then "Input encodings". Here is where you can add GZip support. The API Server will then advertise to API clients (such as smartphone apps) that it supports compression, and if an API client supports this, it will encrypt the data on the wire to send up to the API Server.

For more on HTTP encoding, see RFC 2616:

Consumer APIs and Enterprise APIs - the difference is the data

In the Enterprise API Management article I recently wrote for Computer Technology Review, I draw a distinction between consumer APIs and enterprise APIs. Consumer APIs are APIs which businesses "put out there" primarily in order to drive developers to create apps which drive traffic and generate advertising revenue. Enterprise apps, by contrast, typically connect back into enterprise systems (such as HR or payment processing systems). If you look at enterprise and consumer APIs at a technical level, they look the same: typically both use REST, JSON, API Keys and OAuth. The difference is not the API itself, the difference is the data. When people talk about securing an API, really they mean securing the data which is flowing through the API. Enterprise APIs have high-value data. That is the difference.

An API Server allows you to manage both consumer and enterprise APIs. In the case of a consumer API, although the data is not high-value, you still want to apply an SLA to the API so that you are alerted if it is not performing as expected. In addition, it is valuable to use API Analytics to answer the "Goldilocks Question" (Who's been using my API?). In the case of enterprise APIs, where the stakes are higher, you must ensure that data is protected en route to the API, and that requests are validated (here is a how-to guide to API authentication based on what a key early adopter has done).

Check out the article, and if you want to get your own copy of Vordel's API Server, email

Wednesday, July 11, 2012

OpenID for API Management at the API Portal

Next week I am at the Cloud Identity Summit (CIS) in Colorado. Vordel is a sponsor at CIS, and I'm looking forward to what promises to be an excellent event. Two of the hot topics there are API Management and OpenID. I'm speaking on a panel about API Management on the Thursday of the event. There are also OpenID events on the first two days of the event. 

So, I've put the two things together - OpenID and API Management - in this API Portal demo below. I've used a cookie-cutter "Acme Inc" API Portal to show how (a) a developer registers their API on the API Portal, and (b) how OpenID is used at runtime. I'm using OpenID against Google in order to show it in action, but the Google login part would not (of course) be required if the client is already logged into Google (e.g. an Android phone app). 


Sunday, July 8, 2012

Following real-time API design

It's fascinating this morning to read Steve Chamber's real-time notes on the design of his API. In particular, I was interested in the section on which authentication model to use. It's such a common question: which authentication scheme to use for APIs. Unfortunately, all too often, the answer has been to throw some standards at the problem, without really thinking about whether they make sense. This always reminds me of the world of SOAP Web Services, five years ago, when seemingly everyone wanted to use SAML for authentication of SOAP, when in actual fact SAML is not used to do direct authentication at all. SAML was just the cool technology du jour.

What Steve Chambers has done is to list out the options for API authentication and settled on (my emphasis added) Token Keys with Request Signing.
  • HTTP Basic Authentication is ruled out (why: SSL, Logout, Client retains auth info) 
  • HTTP Digest Authentication is ruled out (why: SSL) 
  • Public Key Authentication is ruled out (why: complexity) 
  • Credentials in Request is ruled out (why: creeds should not be passed in each Request) 
  • Token Keys with Request Signing (of all headers and payload for zero collisions) are selected. 
When I saw this I thought "Yes!". That's because I remember a similar exercise two years ago which also ended in Token Keys (called API Keys in that case) being selected. In that case also, a facade pattern (using a Gateway) was employed in order to separate the API delivery and definition from the back-end infrastructure. It's interesting that in that case we also allowed SSL with HTTP Digest Auth for (as Steve calls them) "pesky humans with a browser" but the Gateway takes note of how the authentication is performed and that is taken into account in policies (the "authentication context").

The other aspect I enjoyed reading about is the REST design constraint. Steve writes:
This API is resource-based, not service-based, as per the REST design constraint.
  • You can access the team artefacts like people bios and written papers.
  • You cannot execute the “give_the_gal_a_raise()” method on a staff object 
Again I thought "Yes!" because this goes back to one of my original bugbears about (firstly) heavyweight Web Services and (now) APIs. Back in the world of Web Services, initially it was seen as part of Distributed Computing and it was all about RPC. Then, Document-Literal SOAP was rightly seen as the best option, and we moved to to that model. That was a good thing. It made overlaying REST on SOAP a bit easier.

Even further back, at the risk of seeming like an old codger, this always reminds me of my early days working as a programmer for an EDI VAN in Dublin moving EDI processes to the new-fangled Internet. EDI was (and is) all about moving documents (resources) around, and updating the status of those resources (purchase orders are approved, etc). At the time in Dublin, it seemed like every other programmer was working in distributed computing (CORBA) at Iona (which I initially encountered as a campus company). That is a different world. It's the difference between doing a POST (aargh) on a method called "approve_purchase_order()" and using PUT to update the status of the purchase order resource. Much of REST is centered on the old ideas which worked, and still work, for EDI. There, I sound like an old codger now.

I'll be following Steve's notes with interest...

Sunday, July 1, 2012

What scales better, the Internet or an ESB?

I love this quote in Jack Vaughan's Techtarget coverage of the Vordel API Server launch:

An API server can provide the policy governance to ensure APIs are tuned for performance and scalability, according to Mike Gionfriddo, CTO at Safeway subsidiary, Blackhawk Network. Gionfriddo’s firm is a provider of prepaid and financial payment cards, and its business is seeing big changes as the Web grows and as mobile devices are used for redeeming gift cards.

“We have been using the Vordel gateway for about two years and we primarily use it to implement our security policies around inbound and outbound Internet traffic,” Gionfriddo told in an email message. “We have been working closely with Vordel on their new API Management offering and we believe it brings a type of serious management around security and governance with respect to APIs.  

“Specifically, we leverage Vordel’s capabilities to help us effectively manage our certificate based security model with respect to our APIs. In addition, we believe that we can use the SLA management function to better govern the SLAs with our partners,” Gionfriddo remarked. 

Is Gionfriddo seeing the rise of REST and a decline in SOAP as others have forecast?  “Absolutely. I could go into a long diatribe about how SOAP is no better than ONC RPC, but I will spare you,” he responded. “The reasoning is simple,” he contined, asking “ What scales better, the Internet or an ESB?” His answer is “REST” 

“REST simply follows the model of Web,” he concluded.