A frequent question about the Axway/Vordel API Server is "Is it possible to
orchestrate multiple calls to different APIs or Web Services?". The answer is
"Yes", and in this blog I'll show how. Along the way, we'll see how to
configure JSON Path on the API Server.
For my worked example, I'm using a weather-lookup scenario. It's now Spring
in Boston, and I'm interested in finding out the temperature using the API
Server. Yahoo provides a great Weather API to retrieve weather information
using REST and JSON. Unfortunately though, it returns the temperature in
Fahrenheit and I'm more familiar with Celsius. So, I want to take the
temperature from the Yahoo output, and feed this as input to the W3 Schools
Fahrenheit-to-Celsius conversion Web Service. This means that I'm
orchestrating to calls, one to a REST JSON API and the other to a SOAP Web
Service.
Breaking down the s... (more)
This Wednesday in Munich I'm speaking on "Plugging Cloud Identity Leaks -
Should your Business become an Identity Provider?" at the Kuppinger-Cole
European Identity and Cloud Conference.
So what does it mean to "plug a Cloud Identity leak"? If employees at your
business find it easier to "login with Google" or "login with Facebook" to
cloud-based apps which they use for business, then that means that your
employees are using a Cloud-based identity over their corporate login. This
means that your employees credentials are being managed by a third-party.
You're losing control, ef... (more)
A common question about the Axway/Vordel API Server is "How do you change its
listening port?". The key to answering this question is to understand what
are the "Services" groups under Policy Studio for the API Server:
What are the "Services" groups?
If you look under "Listeners" in Policy Studio, you will see the various
"Services" groups. In the screenshot below we see "Default Services", "OAuth
2.0 Services" and "Sample Services". These are a way to group different paths
under different ports. So, for example, the sample services are only
available under the port which is define... (more)
It is a common scenario that an API Server must call out to a Security Token
Service (STS) "off to the side" in order to get a SAML assertion issued for a
user. This SAML Assertion then then usually inserted into the request, often
as a HTTP header. Let's see how this is done with the Axway/Vordel API
Server...
Firstly, I've setup an STS policy which is a "REST STS" (or "RESTS" for
short). It takes in a UserID as a REST parameter and issues a SAML Assertion
for that user. Here is the RESTS policy for this, below. Note that it's being
served from the same API Server instance, but ... (more)
A lot has been written about the difference between REST APIs and SOAP Web
Services. The technical differences are well known at this stage. SOAP is
heavyweight, while REST is light and mobile-friendly. However, there is
another key difference which is often overlooked:
It is easy to create SOAP Web Services, but difficult to consume them. It is
difficult to create a good REST APIs, but easy to consume them.
Taking SOAP first: development platforms such as .NET made it almost too easy
to create a SOAP Web Service. I remember seeing MSDN demos showing how, in a
few clicks, you can ... (more)
Mark O'Neill is Chief Technology Office of Vordel. Vordel connects applications to applications, businesses to other businesses, and SOA to Cloud Computing. A regular speaker at industry conferences and a contributor to SOA World Magazine and Cloud Computing Journal, Mark holds a degree in mathematics and psychology from Trinity College Dublin and graduate qualifications in neural network programming from Oxford University.
Derek Granath
Tom Flynn
Patrick Pushor
Bob Evans
