Free "API First" Infographic Poster

This week I wrote a piece on "Becoming 'API First'" for SD Times. It's all about why developers should not be constrained by "Automatic WSDL Generation" style APIs which are generated for them, but instead to design the API first, and then map it back to the implementation. When you becoming "API First", you can design your API at the outset for mobile usage, for versioning, and for intuitive usage. To accompany the article we designed an infographic poster, shown below. You can get a limited edition high quality print copy of the poster by emailing info@vordel.com with the subject line “API First Infographic”. 

Handy Vordel SOAPbox How-To links

Vordel SOAPbox is a free Web Service and Web API testing tool available from Vordel. Here are some handy links to doing common tasks with SOAPbox. Note that although it has "SOAP" in its name, you can use it just fine for REST APIs, as you can see in the third link below. Happy Testing!

Here is the guide to doing a vulnerability assessment of a Web API using SOAPbox

It can also be used to generate SAML and other tokens for SSO testing.

Here is it used to connect with a password to a REST API.

Vordel introduces the API Server

Big news today: Vordel has introduced the Vordel API Server.

What is an API Server? An API Server is designed to provide everything you need to deliver APIs. This includes everything from management, monitoring, security, through to transformation and legacy connectors. This is the analogy with an Application Server. It provides a platform to deploy apps. An API Server provides all the services needed to deploy APIs.


How is it different from traditional API Management? Traditional API Management products assume you already have the APIs in place, to manage. An API Server goes a step further and actually delivers the APIs themselves. Plus, it provides all the management too. It's API Management and more.


How can I see it in action? Right here. Check out the video below:

Job Posting: Cloud and Vordel Skills - Blackhawk Network, California

Blackhawk Network in California are looking for a systems engineer with Cloud and Vordel skills. The job details are here on the Blackhawk Careers site. This is a very exciting opportunity for someone interested in working in a dynamic API and Cloud environment. If you want more details about how Blackhawk is using Vordel products to deliver their APIs, check out the recorded webinar here (no registration needed).

Responsibilities listed for this job are:

Define cloud deployment requirements by working with engineering organizations in support of their development and test functions Deploy in multiple public and private clouds, e.g. Amazon (AWS) , Rackspace, Cloudstack Work with IT Network and Security organizations to standardize infrastructure builds to facilitate a secure yet flexible operating environment Configure, administer, debug and troubleshoot Vordelsecurity gateway software and devices in support of application data flows Leverage industry best practices in defining and tuning appropriate on-demand cloud deployment architecture Programmatically automate routine cloud deployment, administration, and monitoring tasks Integrate cloud access and authorization administration with enterprise Microsoft Active Directory services in support of single identity and sign-on initiatives Be dynamic and capable of continuous learning and quick integration of new learning in daily work to accelerate and improve team capabilities Provide operational support of cloud/development environments in support of both the engineering and IT organizations

Vordel on Booth S24 at Gartner AADI in London his week

I'm looking forward to the Garner AADI Summit in London this week. Some great looking sessions on the agenda. Who can resist a session with a teaser like "Who needs governance in their integration, SOA and Web API projects? Everybody. Who accepts to be governed? Nobody". Vordel is on booth S24, check us out if you are in London this Thursday and Friday...

BYOD - not only desirable but mandatory?

Joe McKendrick has a very insightful piece about how BYOD will become mandatory in some workplaces. It just makes too much sense. He cites the example of California's Department of Health Care Services (DHCS). Why pay for devices which employees will only use grudgingly? The key, of course, is to manage this. Rather than placing corporate data on the devices, it's better to move to an API model whereby access to corporate information is achieved via secure APIs

Job Posting: London-based Investment Bank - SSO Architect with Vordel Skills

This job, posted earlier this week, is for an SSO Architect with Vordel skills. Other skills needed include LDAP, Kerberos, SAML. Vordel ninjas who follow this blog may be interested in checking it out.

Pro Tip: How to use the Vordel Gateway to perform LDAP against Active Directory LDS (Lightweight Directory Services)

Microsoft Active Directory LDS (Lightweight Directory Services) is a convenient lightweight LDAP directory which you can download from here: http://www.microsoft.com/en-us/download/details.aspx?id=14683. 

Here is how you can configure it, and then configure the Vordel Gateway to do authentication against it. 

After I installed LDS, I added the "User" user class. I set my domain to be cn=Employees, DC=vordel, DC=com

I added an Admin user using ADSI Edit (see below). Then in Policy Studio you can configure the connection as shown below. Use the convenient "Test Connection" button to make sure you've set it up correctly:

Connect to your LDS instance using ADSI Edit (it's in Administrative Tools in the Control Panel):

You need to add an admin user and make sure they have Administrator role:

Now add the user we are going to authenticate, and set their password:

For this example, I next setup an authentication filter then in Policy Studio for the Vordel Gateway, using the "Base Criteria" of "CN=Employees,DC=vordel,DC=com". The User class is 'User' LDAP Class, since that is the user class I am using in AD LDS. The User search attribute I used is givenName [Tip: Ensure that if you choose "givenName" as the "user search attibute" for authentication, then you give the user in LDS the correct value for the givenName attribute]. Other options for the User search attribute are CN (Common Name).

That's all there is to it. Setting up Attribute Lookup (using LDAP) to LDS in the Vordel Gateway is a very simple process once you have the connection setup, as described above. 

Stats on API usage and reasons for API adoption

Loraine Lawson at IT Business Edge has a good round-up of many stats related to API adoption, including this from Vordel's own survey on reasons behind API strategy:

50 percent. Say APIs to integrate new channels.

25 percent. Say APIs will be rolled out for mobile apps.

15 percent. Want to build a developer community.

Silicon Republic covers the Vordel Mobile Gateway

Gordon Smith over at Silicon Republic has written an article on the Vordel Mobile Gateway, linking it to the growing BYOD (Bring Your Own Device) trend. Check it out over on the Silicon Republic site

REST-Enabling a WebLogic Service

Application Servers typically generate SOAP services not REST. Because it's easier for apps to consume REST services, you often find yourself needing to convert SOAP to REST. If you find yourself needing to this in the context of WebLogic, check out Niall Commiskey's guide to REST-enabling a SOAP service on WebLogic. 

Database driven SLA's for mobile APIs

Enforcing usage limits is a common requirement for mobile APIs. This ensures that the mobile API is not abused, and also allows for a "Freemium" model where usage of the API is free up to a point, and paid for afterwards.

Vordel's Mobile Gateway can be used to enforce SLA (Service Level Agreement) limits for mobile API access. In the video demo below, I'm showing how SLA limits are configured using a throttling rule. Traffic over the limits results in an alert being raised. I am retrieving the SLA limits from a database. In the screenshot below, we see the simple policy being used. I've opened up the filter which is looking up the SLA value from the database:

Next, I am using a Throttling filter to enforce the usage limit. You can see that I'm using a variable (with the dollar sign) to include this value in the policy. The advantage of this method is that any changes to SLA values, or additions of new clients, doesn't need any change to the policy at the Gateway.

Finally, here is a video of the usage limits in action, using a mobile app running in the Android emulator: