Quantcast
Channel: vordelfeeds
Viewing all 236 articles
Browse latest View live

Netflix goes Private: Is this the end of the Public API golden age? And is that a bad thing?

$
0
0
ProgrammableWeb has published a story about how Netflix is taking its API private. In the article, Patricio Robles writes that:
"Effective immediately, Netflix has stopped issuing new public API keys to developers and is no longer accepting API affiliates. It is also putting the message boards on its developer portal into read-only mode"
So what is Netflix doing instead? It is focusing on the known developers who wish to use its APIs. As the ProgrammableWeb article explains, this "small group of known developers" is what is contributing mostly to the usage of the Netflix APIs. This makes perfect sense.

But wait! Doesn't the API world revolve around Public, Open APIs? As anyone who has ever been to an API conference knows, most presentations show the famous upward-growing chart of Public, Open APIs listed in the ProgrammableWeb directory.

But there is another chart, the infamous "iceberg chart", also used at every API conference, which shows that Public, Open APIs are just the tip of the iceberg.

So if Open, Public APIs are just the tip of the iceberg, then how popular are the other types of APIs? The story quotes Netflix's own Daniel Jacobson, who wrote back in 2012 about Public APIs that:
“The potential shortcomings surface because this model assumes that a key goal of these APIs is to serve a large number of known and unknown developers,” he wrote. “The more I talk to people about APIs, however, the clearer it is that public APIs are waning in popularity and business opportunity and that the internal use case is the wave of the future.”
http://www.programmableweb.com/news/why-rest-keeps-me-night/2012/05/15 
So clearly Internal APIs are also important. But are there more types of APIs than Open/Public APIs and Internal APIs? Yes, and in fact Randy Heffner from Forrester defines four types of APIs:
  • Internal APIs
  • Partner (B2B) APIs
  • Open APIs
  • Product APIs
Public APIs fit under "Open APIs" in this taxonomy. Let's look at the other categories of APIs:

Internal APIs, as the name implies, are used inside organizations. As Daniel from Netflix says above, these are "the wave of the future". In fact, Kin Lane has written that Internal APIs (managed in an internal SOA) are the secret of Amazon's success

Product APIs are provided by vendors, and in fact Axway's own APIs for the Axway 5 suite are a great example. Axway's APIs allow customers to, for example, provision new B2B trading partners via an API. Another exciting example of a Product API is BMW's API for their Connected Cars (check out this webinar with IC-Consult about how OAuth and API Gateways are used to secure these APIs).

Partner (B2B) APIs are used to connect businesses together. In Axway we often see banks and insurance companies connecting via Partner (B2B) APIs (insurance is often "white labled" by banks within a financial product such as a mortgage, and APIs provide the link back to the insurance provider). 

This taxonomy by Randy at Forrester is very useful. But how prevalent is each type of API? The answer can be found in a webinar which Randy presented  on API Strategies with Axway last month, which you can catch in the recording on-demand on the Axway website. The webinar had a phenomenal sign-up, showing the huge interest in API strategy. During the webinar, we asked a polling question: "What types of APIs are you using?". The answers were very interesting:



Notice how Open (Public) APIs trail both Internal APIs and Partner (B2B) APIs. At Axway, we are seeing our customers putting significant business through their APIs. Given Axway's B2B DNA, this includes significant B2B traffic which we are enabling through the new medium of REST APIs. All of these business APIs are adding a commercial edge to the API world.

So who is leading the trend towards business APIs? Let's look at two examples. Firstly, CVS Caremark:



CVS Caremark has an API - at https://developer.caremark.com - which is used for prescription lookup. So is this API intended for use by just any developer who is throwing together an app? Clearly the answer is "no". Just like the Netflix API, it's for a smaller group of known developers who have valid use cases for the API, and a business relationship with the API Provider. In fact, CVS themselves write on their API portal:
"...commercial use of the API is allowed only with prior permission. Requests for API keys intended for commercial use are reviewed by staff."
https://developer.caremark.com
Let's look at another example: Dun and Bradstreet:


The Dun and BradstreetAPI is a classic example of a B2B API. It's for organizations who have a business relationship with Dun and Bradstreet to use, in order to expand their reach to mobile devices, CRM systems (including SalesForce.com) and others. Again, it's not an Open, Public API for any random developer to use.

What we are seeing with Netflix, CVS Caremark, and Dun and Bradstreet is the API Economy growing up. We are no longer fixated over Open, Public APIs. Instead, we see that Internal APIs, Partner (B2B) APIs, and Product APIs are equally (if not more) important. Think that the initial API gold rush was big? Now that APIs mean business, the real API gold rush is just beginning. 

Webinar: Enabling B2E - Business to Employee - mobile apps with OAuth 2.0 and the Cloud

$
0
0
A couple of years ago, I presented a webinar with Scott Matsumoto who is Mobile Practice Director as Cigital. The topic was mobile security patterns. We talked about the role of an API Gateway in a two-stage Cloud-to-On-Premises architecture, used to deliver APIs for mobile apps.

To this day, we've continued to get great follow-up questions about this webinar. So, by popular demand, we are bringing it right up-to-date and running a Version 2.0 of the webinar which talks about how OAuth 2.0 changes the game and further helps enable mobile security. The webinar is tomorrow, 19 June, at 10am US Eastern Time.

We are also focusing on the B2E (Business to Employee) case. We see this a lot, especially in larger organizations, where apps are developer for mobile sales people and field workers. Here is a teaser of the architecture we'll be talking about. Sign up for the webinar to see Scott and I discuss the architecture, and ask questions.



API Workshop in Detroit - Tuesday 24 June - Connected Car, OAuth, Office365, SalesForce.com, and more

$
0
0

Next Tuesday, June 24, in conjunction with our partners at IC-Consult, we are running a half-day API Workshop in the Detroit area. 
I'm very excited that we have a great guest speaker, Robert Foster from IC-Consult, who will be talking about about the BMW Group case study, explaining how secure APIs drive innovation in the Connected Car area. 
In the technical deep dive part of the API Workshop, we'll be covering:
  • How to secure REST APIs - OAuth 2.0 and more
  • APIs for Mobile Apps 
  • SalesForce.com and other Cloud APIs
  • Microsoft Office365 and Google Apps Single Sign-On
It's also a great opportunity to pick up some free Axway schwag ;-) . I recommend the mobile battery packs. 

The location is Laurel Manor at 39000 Schoolcraft Rd. Livonia, MI. 48150. Registration for the API Workshop is free. Hope to see you there! 

Prebuilt OAuth connectors for SalesForce.com

$
0
0
One of the neat things about the latest (v7.3) version of the Axway API Gateway is that it comes with pre-configured OAuth 2.0 connectors for SalesForce.com. You can find these under External Connections in Policy Studio, as shown in the screenshot below:


The advantage of this feature is that it means that users do not have to worry about the intricacies of OAuth, or the nuances of how OAuth is implemented differently by different identity providers (IdPs).

Using the prebuilt SalesForce.com OAuth 2.0 connector, it is quite simple to setup a connection to SalesForce.com and then take advantage of the Axway API Gateway's monitoring to provide visibility on your SalesForce.com usage:


Monetizing mobile apps - Comments on McKinsey Report

$
0
0
McKinsey recently produced a report entitled "Monetizing mobile apps: Striking the right balance". It talks about how APIs can drive revenue for organizations. The report is certainly useful to further drive awareness of APIs, but there are some comments which I have on it.

The report focuses only on customer-facing mobile apps. But, organizations are gaining significant value by deploying APIs to enable employee apps (think of field-sales apps, or apps for employees working in the field installing products). Last week, we ran a webinar on Business-to-Employee Mobile Apps with Scott Matsumoto from Cigital where we ran a poll about what kind of apps which organizations are enabling through APIs. Customer-facing apps topped the poll, as expected, but look how important internal employee apps are:


I also think the McKinsey report suffers from some selection bias, by only examining Public APIs which are in the ProgrammableWeb directory. When organizations deploy private APIs or partner APIs, enabling mobile access in this way, they don't appear in ProgrammableWeb. These APIs may be paid for as part of a larger business service, or, for an Internal API, may be paid for within the organization as a cost center.

Manfred Bortenschlager makes some great points about this McKinsey report in his blog, writing:
"There are reasons not to pursue APIs, of course, starting with the desire of many companies to have more direct control over their data." 
?? APIs do give direct and manageable control about data. 
“But our analysis indicates that APIs are generating revenues in one of three ways for the companies that choose to contribute their data.” 
This analysis is apparently not very in depth. Simply looking at John Musser’s talks there is at least a dozen of business models for APIs. http://manfredbo.tumblr.com/post/90063148340/monetizing-mobile-apps-striking-the-right-balance
I was also waiting for them to mention John Musser's excellent analysis of payment models for APIs. Surely no analysis of API payment models is complete without even a reference to John Musser.

Also, to Manfred's point, an API Gateway is what is used by organizations to apply "direct control over their data" when they deploy APIs.

All in all, the McKinsey report is useful, but with the caveat of the comments above. Great to see so much awareness of the benefits of APIs across the board.

How to associate a single API Gateway with multiple IP Addresses in a multi-homed environment

$
0
0
One of the neat features of the Axway API Gateway is the ability to deploy it in a multi-homed environment, so that it is associated with multiple IP addresses. The requirement is for a single API Gateway to listen on multiple IP Addresses, on the same port (usually the SSL port: port 443).

This is often done because an organization wishes to deploy API Gateways virtually in multiple places on the network, while using the same server to run the API Gateways.

To do this, the first step is to associate the multiple IP Addresses with the machine running the API Gateway. In this example, we associate two IP Addresses (with two corresponding subnets): 192.160.0.10 and 10.10.1.10. This is done at the OS layer.

Next, we use Policy Studio to setup our two listeners, corresponding to the two zones (which we'll imaginatively call "Zone 1" and "Zone 2"):




Note where the IP addresses are configured above. Users of the API Gateway might be used to seeing an asterix ('*') in the "Address" field under the port configuration. The asterix means that the API Gateway binds to every IP address available on the machine. By specifying the IP address in the "Address" field, we are saying that the API Gateway will only bind to this port for this listener.

Also notice above that both listeners are listening on the same port, which is the SSL port 443. Normally if you have two applications listening on the same port, there is a clash. But in this case, the API Gateway is listening on two ports on two different IP addresses.

Underneath our "Zone 1" and "Zone 2" listeners, we can associate different paths. So,  https://192.160.0.10/myAPI will be handled under the "Zone 1" listener.

Notice also that different certificates can be used for the different listeners. The certificates themselves can be generated using the Axway API Management solution (under "Certificates and Keys" in Policy Studio). If you have multi-homed your API Gateway to multiple addresses which are associated with multiple machine names (e.g. "apis.mycompany.com" and "internal.mycompany.com") then you can issue certificate within Policy Studio for these names, then load them using the "X.509 Certificate" button in the "Configure HTTPS Interface" screen above.

Happy multi-homing! There's no place like a (multi)home :-)

API Workshops roll on - Detroit / Connected Car - and next stop Munich June 10

$
0
0
Last Tuesday in Detroit, along with IC-Consult, Axway ran an API Workshop in Detroit. Many attendees from the major car companies were present. One of the big conversation topics was Social Login ("Login with Google", etc). This is something which we saw can be implemented using the Axway API Gateway, and in fact the API Gateway can be used to map from a Social Login to a local on-premises Identity and Access Management product like Oracle Access Manager (here's a description of the Google to Oracle OAM mapping in action). That allows for a hybrid Cloud/On-Premises identity approach.

Aside from Social Login, we also saw SalesForce.com integration, and the API Developer Portal in action. The highlight, though, was when Robert Foster from IC-Consult ran through the BMW Group Connected Car case study. Here you can see Robert showing a video clip of Pierce Brosnan (as James Bond) with an earlier incarnation of the connected car (the chase scene from "Tomorrow Never Dies"):


The API Workshop tour rolls on. Next up is the API Workshop in Munich next week - 10 July. Sign up for free if you're in the area and interested in API Security, OAuth, Cloud/Social Login, and all things API-related :)


Looking forward to the API Management & REST Security Workshop in Sydney - 23 July

$
0
0
I'm happy to say that later this month, on 23 July, we're holding an API Workshop as part of the Axway Connections event in Sydney, Australia. We'll be covering REST API Security (always a hot topic), plus Social Login (OAuth and OpenID), SalesForce and Office365 connections, and mobile API access. Registration for the API Workshop, part of the overall Axway Connections event, is free using this form. The API Workshop is located at the Pullman Hotel on Sydney Harbour, which has a nice view as you can see below:
Pullman Hotel - Sydney Harbor - Location for 23 July API Workshop
For those of you who haven't attended an API Workshop before, it's a great way to see API Management and security in action, and learn about technologies such as OAuth.

In addition, as part of the Axway Connections event, we have some great speakers lined up:

  • Ian Gibson, CIO at SuperChoice. Ian will be talking about the Superstream protocols (including ebMS v3 and AS4, which are you can read more about here).
  • Richard King, Head of IT Risk & Security at Telstra Global. Richard will be talking about hybrid integration in his talk on "Enabling a Digital & Cloud Future for Telstra Global"
  •  Chris Solomon, Integration Architect Middleware, will be presenting the New Zealand Customs Service case study
And I like the look of the finale at the end of the day :-)

The Old World meets the New World: Cheese & Wine Tasting
Join us for a fun-filled networking session where we conduct a tasting of some of the best vintage wines Australia and France have to offer whilst enjoying selected cheeses and canapés. This final event is limited in numbers so please clarify when registering if you can, or cannot attend.

Registration for the event is free, via this form.

Why do some boarding passes say "API" on them?

$
0
0
Since I work in the API Management business, I always smile to see "API" on my boarding pass (well, as much as it is possible to smile when checking in for a flight). You can see "API" on the boarding pass for my current trip to Germany below:


But what does "API" mean on a boarding pass? The answer is that it stands for "Advance Passenger Information". It's information about passengers which is sent ahead of the flight, often for immigration/customs purposes, and for security of course.

However, there is in fact a link between this API and the "other" API (the Application Programming Interface). The Axway API Gateway is used to securely send API information between some countries. The API Gateway ensures that the data is formatted correctly, sent over an authenticated link, and is signed and encrypted. It's an example of an API where delivery of the data is absolutely essential, and this is assured by the API Gateway. So it's an API for API" effectively :-)

SOA, ESB, TIBCO, and Axway API Gateway skills required in Maidenhead UK - Three UK Job Posting

$
0
0


Readers of this blog might be interested in this Systems Integration Solution Designer Job Posting from Three UK, located in Maidenhead which just outside of London.

Skills listed include: TIBCO ActiveMatrix, Axway API Gateway, and Enterprise Java, as well as knowledge of SOAP, web & RESTful services.

Telstra Hybrid Integration Case Study next week at Gartner AADI Sydney

$
0
0
Next week I'm excited to be attending Gartner AADI Sydney, where the Axway sponsor session features Telstra's Richard King speaking about Hybrid Integration, at 3.15pm on Monday July 21. Hybrid Integration, and the Hybrid Integration Platform (HIP), are very exciting topics in integration at the moment. Connections between on-premises and Cloud services are enabled in this way, all through APIs.

Here is the preview of the talk:
Innovations in Cloud, Mobile, Social Media and Big Data are revolutionising how Telstra International goes to market to engage with their customers, employees and suppliers. Richard shares experiences of how the business addressed the challenges of legacy integration, governance and politics to implement a framework to mobile-enable enterprise applications and govern services across public, private and hybrid cloud environments. 
http://events.gartner.com/#/en/navigator/APIN20A/agenda/24353/sessiondetail/speakers-tab 
I'm looking forward to the session, and to catching up with so many partners, customers, and friends in Australia. Maybe not looking forward to the long flight so much though... :-)

APIdentity at Cloud Identity Summit next week

$
0
0
My colleague Ross Garrett is speaking next week at the Cloud Identity Summit on the "APIdentity" track. "APIdentity" is a neat mashup of "API" and "Identity" - I like it. Catch Ross's talk at 2.10pm on Monday 21 July:
API Security for the Cloud: Tales from the Trenches
Cloud technologies and mobile devices are transforming interactions with organizations via APIs. APIs present an endless opportunity for businesses to generate revenue, engage customers and collaborate with partners; Gartner even predicts 50% of B2B collaboration will occur via Web APIs by 2016.
This API Economy creates new IT complexity and presents risks for businesses when not implemented and managed securely. This presentation will discuss examples of organizations securing APIs, examining the API security state of play for the cloud. Questions that will be answered include:
  • How are organizations implementing OAuth?
  • How are they Managing Keys?
  • What are real-world examples of API security?

Configuring OAuth for initial LDAP Authentication

$
0
0
Although OAuth is not for authentication (the "auth" is for authorization), it usually presupposes that an authentication event has taken place. In the case of the Axway API Gateway, you can use the internal use store for this authentication, or you can use a third-party repository like LDAP. If you want to switch to LDAP, you can simply choose a different authentication repository under "Validate credentials against this repository" in the OAuth 2.0 policies in Policy Studio as shown below:


If you want to add a new authentication repository, you can find these under "Authentication Repositories" in Policy Studio, as shown below:


Note that other options include CA SiteMinder, Oracle Access Manager, IBM Tivoli Access Manager, and others.

Video: Mobile App calling APIs, using the Axway API Portal and API Gateway

$
0
0
This week I am in Sydney, Australia, for Gartner AADI this Monday and Tuesday, then the Axway API Workshop here on Wednesday (still time to register if you're in Sydney!). The API Workshop ends with a wine reception, pitting French wines against Australian wines. In keeping with the theme, my colleague Charles Poulson and I have worked on sample APIs and apps, to see how an API Portal and API Gateway are used as the API backend for mobile apps.

In the video below, you can see a "Wine Chooser" sample Android app which consumes an API that's registered in an API Portal, and see the mobile API usage reporting being gathered and reported. We also see API Keys issued at the API Portal. Come along to the API Workshop on Wednesday to get your hands on the real thing! (the app and the wine :-) ).


ViewDS and Axway - PEP/PDP interop using XACML for externalized authorization

$
0
0
Andrew Sciberras, the man with the most impressive mustache in Identity (until he shaved it off!), has written a very useful post on how Axway and ViewDS interop together using XACML to enable external authorization for SOA and APIs.

The interop announcement, which coincides with the Cloud Identity Summit in Monterrey, speaks about how customers can now leverage ViewDS and Axway together in order to create complex authorization rules. An example of such a rule would be "Only the patient or their doctor can access a medical record, or the patient's parents or guardians if the patient is under 18 years of age". These types of policies are particularly suited to XACML.

The overall architecture is shown below:



Are REST APIs Inherently Insecure? - Speaking at ISC2 in Atlanta in October

$
0
0
REST security is a hot topic. One of the reasons for this is the continued blowback from the over-complexity of the WS-* specifications. These specifications,  including WS-Security, WS-Trust, and WS-ReliableMessaging, and were notorious for being difficult to comprehend. In fact, people wrote whole books about Web Services Security :-) . One of the benefits of REST is simplicity. But, on the flipside, the lack of standards for security has led to the proliferation of ad-hoc security approaches such as the use of API Keys. API Keys are frequently used for API "authentication" often without much regard for potential attacks such as replay attacks.

But, by using an API Gateway approach, is it possible to layer on security for REST APIs? Could they (shock, horror) co-exist with heavyweight WS-* style SOAP web services? I'll be talking about this topic in my talk on "Are REST APIs Inherently Insecure" at the ISC2 Security Congress in October in Atlanta. Hope to see you there?



The Value of API Monitoring and Analytics

$
0
0
API Monitoring and Analytics are a very important part of API Management, because they answer question "Who is using my APIs", as well as providing the basis for monetization of APIs.

In the Axway API Management solution, we provide web-based monitoring of APIs both in real-time and as reports. In the screenshot below, we see API Analytic in action, with information about API usage, and the ability to generate a PDF report:


An example of a generated PDF report is shown below. Everything is customizable.


You can also search for specific transactions in Analytics using drop-down forms as shown below:



You then see all of the information about the API call, including the steps as it passes through the API Gateway:


You can also see the time for each step, as shown below. This is very important for diagnosing why an API call might be taking a long time. Using Axway API Management, you can see all the dependencies exactly, and do a full root-cause analysis. If someone says "My mobile app is running slowly", you can see exactly why that is (e.g. a back-end server is running slow). Notice the times for each step in the Gateway shown below:



In the Traffic Monitor, you can also see the times for requests and responses:



In addition, it is common to single out certain information from API traffic and use this within analytics. For example, your API calls may contain a field called "Waybill number". You can isolate the value of this field using JSON Path (in the case of JSON) or XPath (in the case of XML). Then, you log it as a "custom attribute" in Policy Studio as show:

Now that you've singled out this "Waybill number" as a specific attribute, you can then search for it explicitly.

You can also set what exactly is logged, if you want to log for tools such as Splunk to crunch the data.

Top 10 Security Issues for REST APIs - Webinar with Gunnar Peterson on September 18

$
0
0


REST API Security has come a long way from being a case of "Just use SSL"... or has it? On September 18th at 11am US Eastern Time / 4pm UK, we're running a webinar with Gunnar Peterson on the Top 10 Security Issues for REST APIs.

One of the big criticisms of SOAP Web Services was the complexity of the security standards such as WS-Security, WS-Trust, WS-Policy, WS-PolicyAttachment... the list goes on. People wrote whole books about them ;-) . In the case of REST, it can worryingly seem like a case of the Wild West (the "Wild REST"). Now, there are standards such as OAuth, but also there are many conventions such as API Keys which are sometimes implemented insecurely. Even in the case of OAuth 2.0, the implementation itself must be secured. Look out for this, and more, in Gunnar's definitive Top 10. 

And because the topic of REST API Security is so hot, we're running the webinar twice :-) . If you're in the Asia-Pacific region, you can attend Gunnar's REST API Security webinar on Tuesday 23 Sept at 10am Hong Kong / 12 noon Sydney/Melbourne time

The power of Real-Time APIs - Apple Watch and BMW

$
0
0
One of the most exciting parts of this week's Apple Watch launch was the example of the BMW watch app. This app allows you to see the charging status of your BMWi electric car, right from your wrist. You can also check the status of the doors of your car (important information such as if they are locked or not!). Although the star of the show was the watch app, APIs had a cameo appearance, since the information shown on the watch is fetched in real-time from APIs.


It happens that there is already an example of a watch app for BMIs cars, pulling data in real-time from APIs. If you want to find more about the underlying APIs, check out the Axway/IC-Consult webinar about how APIs power the connected car. As you can see below, not only are watch apps involved (in this case the Samsung Gear example), but also mobile apps.

The key is that the data is fetched in real-time via APIs to the watch. By the nature of a watch interface, a user does not want to be pressing buttons to get information, or to refresh data. This brings us to another announcement this week. Here at Axway, we released version 7.3 of our API Management solution. One of the key innovations is around real-time API delivery. We do this by embedding a messaging provider which, combined with HTML5 WebSockets, enables lightweight real-time API access to backend systems. This is ideal for the latest use cases including real-time financial information, real-time betting and gaming information, and, in the case of the Apple Watch and BMW, real-time Connected Car information.

The smart watch era promises to also be the real-time API era. Here at Axway we're very excited about this. 

Mobile backend with a Scottish twist - this Thursday in San Francisco

$
0
0
At our Axway API Workshops, we use an example of a mobile app using the API Gateway as a mobile backend. It happens that Thursday's API Workshop in San Francisco coincides with the Scottish independence vote, so the app we're using will have a Scottish theme...

In an instance of the Axway API Portal, I've configured a Scottish Voting API which simulates a voting API. The options, as in the real vote, are "Yes" and "No". 

As you can see in the screenshot below, I've configured API Key authentication for my Scottish Voting API. The API Portal has a handy "Try It" feature so that I can make test calls to the API, right from the API Portal (it's the "Try It" button on the right).


I've also registered an app at the API Portal, which will consume my Scottish Independence Vote API. Because the API is protected using API Keys, you can see that the API Portal issues an API Key to my app. In the API Workshop, we show how the mobile app makes use of this API Key to call the API, and how the Axway API Gateway enforces the API Key authentication. In the screenshot below, I've scribbled out the API Key in red:


There is also a quota applied to my app - it can send 100 messages every 1 second. When we look at the API traffic at the API Gateway later, we'll see that the remaining quota count is returned as a header to the app which calls the API.


Now let's look at the main app configuration. You can see its icon, plus the fact that it will access the Scottish Independence Vote API. 



Here's the app itself in action, on Android. You can see that I'm using the text from the vote itself ("Should Scotland be an independent country?").  The app calls the API which I've registered at the API Portal. It uses API Keys to authenticate.



The API Gateway shows the votes rolling in - as you can see below. It also shows any requests which are blocked for security or other reasons:



We can also see the API calling info over time, and zoom in on particular times to see more info:



And remember that quota I mentioned above? Here you can see the remaining quota information returned in a header, which is helpful information for the calling application:



That's how easy it is to use the API Gateway and API Portal as a mobile backend. Whatever the outcome of the Scottish vote on Thursday, I'm looking forward to walking through the Axway API Portal and API Gateway at the API Workshop in San Francisco this Thursday. Sign-up is free, hope to see you there.

Viewing all 236 articles
Browse latest View live


Latest Images