API Managmeent market is quite big, makes sense for Amazon to get on board.

Imagine this: You are BigCorp USA Inc. and have a bunch of internal SOAP-based web services that are 10 years old and cost a fortune to maintain.

You hear someone will pay you to use them, but SOAP sucks. So you could either go and change your APIs (and probably break a bunch of internal processes) OR you could use a gateway to sit in front of them and translate in bound / outbound requests. Now you can charge people for your APIs!

Scenario 2: If you're an indie dev/ startup but dont want to run EC2 infrastructure, Lambda + Gateway = Cloud service, without any heavy lifting, servers and cost effective. It's development lego. Kind of like Parse.

Scenario 3: You have an API for your app, now you wnat third party devs to use it.Your API is not set up for that kind of access (multi-user security, throttling, quotas, analytics etc.) - solution: shove a gateway in front of it.

#1 is exactly what I'm working on right now; turns out there's a huge market for this sort of thing. We're using an API gateway (Axway/Oracle) to build an "API Mullet" (all SOAP in the back, all REST in the front), and while I have some qualms with the tooling, the idea of an API gateway is very sound.

"API Mullet" has got to be my favorite description of this type of system. Well done.

I can't take credit for it, alas. It was from an Axway blog post. It's sort of backwards too, if you think about it - business in the back and party in front.

I don't know, the "front" is all business - ordered, structured, conforms to the standards. The back is a jumbled, messy, non conforming. It's a party back there.

API Tellum?

Out of interest SOAP services tend to be message/operation based, while REST is deliberately not this.

How do you go about proxying REST style requests to a SOAP backend?

Can't speak for the parent but having tackled similar efforts before I find that almost all APIs regardless of the implementation flavor (including SOAP and RPC) are readily understood as CRUD systems creating/reading/updating/deleting things), and the mapping from CRUD to REST is straightforward. In practice this generally means mapping from a SOAP call like `SetPostAuthor` to a REST call like `PUT /post/:post_id/author`. There are always some gnarly bits along the way, but the basic structure usually comes together pretty easily.

Yup, petty much. If you're willing to be a little flexible in your application of RESTful concepts and are okay with your abstractions leaking a bit, it's not especially tough.

That's the easy case.

A harder case is when you have a "service" layer which also has a large collection of queries at various levels of abstraction.

These map poorly into resources, where you want a single level of abstraction per resource. And they map badly to legacy consumers, who've grown comfortable to having a collection of special knobs and dials perfectly shaped for their exact needs.

Heh, I never thought I'd meet an Axway product user on HN. What are you using? Gateway? Integrator?

Gateway is pretty non-specific if you're talking Axway. It could mean XFB Gateway, Gateway Interchange or API Gateway... and I'm not even sure that's the whole list.

I meant XFB. It was the only product that was referred internally just as "Gateway". "Gateway Interchange" was "Interchange" and "API Gateway" was "API Gateway".

Gateway, under oracle branding.

me too! (not the oracle version though) :(

It does suck a bit, I've also sent Layer 7 into production which is just as bad as Axway. Typical Vendorware.

The AWS Gateway is pretty enticing. Solves lots of the API Gateway problem space very quickly and super cheap. We could run our production instance for about $2 a month I reckon, vs a 6 figure sum for the vendor tech.

May God have mercy on your soul :o)

;_;

Just curious, but why Oracle-branded rather than direct?

have you look at the open source KONG https://github.com/mashape/kong ?

do you have a website?

Not really, why do you ask?

API management is not big. Is under $500M/year [1] - plus most of the features are becoming commodities. Take a look at the open source KONG API gateway [2]

[1]https://www.forrester.com/Sizing+The+Market+For+API+Manageme...

[2] https://github.com/mashape/kong

It's still an interesting proposition for new development... front end published to S3/Cloudfront, with the backend running in Lambda responders, and an API layer using this for a communication bridge... full scale flexibility with very low administrative overhead...

At a larger size, it may be more expensive than a roll your own, but for an independent idea that you just want to build something as a software/service and if successful be able to scale and handle extra load, it isn't a bad idea.

This is really the missing piece to Lambda in my mind... though being able to act as a bridge for legacy SOAP/WS-* services is pretty nice too. I've written a lot of pretty small node service that act as a bridge to SOAP based services the past few years... though most of those have been for internal use, and not sure how well that translates here.

Agreed that it's moving down the value chain, many other open source projects out there doing similar things. There's also Tyk Open Source API Gateway (https://tyk.io) and API Umbrella (http://apiumbrella.io/), and APIAxle, though that's been around for a while now.

Also API market is intended to grow to $660 million in US by 2020 and over a billion worldwide (http://blogs.forrester.com/michael_yamnitsky/15-06-07-the_ap...). So it's definetely not small.

Is small from a VC prospective. Especially in 2015-2020. Everything under 1B is tiny. Plus, when there are soo many players you will end up fighting like crazy just the get bread crumbs.

In web scraping industry, can confirm.

there is no real active development on apiaxle and api umbrella is low looking at their pulse.

quick side question, what software market have avoided becoming commoditized?

This removes infrastructure from the equation entirely. You already had AWS Lambda which could run small pieces of Java or Javascript code when certain events were fired from other services (all without running a server yourself). The missing piece was something that catches HTTP requests and passes them to a Lambda function. This service seems to fill that gap.

It means you do not need to think about x instances that serve your API anymore. You just upload your Lambda function, wire some API path to it and pay per request. For smaller APIs this will be probably be negligible. Could be a gamechanger!

Yeah that's why I'm excited about this. I have a small instance that just runs a sort of "node proxy" to lambda, it's cheap ($11 / month or something), but annoying to run just to be able to connect to lambda. Now I can get rid of that.

This is a pretty big deal, even if just for the fact that this plus Lambda eliminates fixed costs.

Rather than running an API server 24/7, you can write your API as a set of functions that cost you money only when they're actually invoked.

Let's just say that I know of a big cloud company who now has 1 major internal project which has been obsoleted by what Amazon releases now.

If you have a large cloud platform, an API gateway is priceless.

Especially if you have single sign on and therefore can use auth tokens for everything.

I don't see why they'd be obsoleted. If I have infrastructure already setup on say, Azure, and Azure comes out with something like this, I'm going to use that instead of AWS, simply because it's familiar territory (not to mention LAN-level latencies between the gateway and my other API servers)

Because they invested a lot of engineering effort in making an API gateway and judging by the speed of development for internal projects versus AWS development soon most if not all of its functionality will he surpassed by the AWS version.

And because everything for them is already built on top of AWS.

It depends on the features of the gateway, but you can add or centralize various functions and not have to make them a part of every API ever. So you save in not having to duplicate that code as well as being able to change it everywhere rather than having to fix one API at a time. Okay, sure, maybe you had a library or something that each API used, but this does make managing it very simple and simple is good, especially if you have hundreds or thousands of APIs.

In the API Gateway I work with allows you to do authentication within the gateway and then delegate responses to the back end API (which can still have its own security, if you really want it, but usually is just hidden on an internal network). It works pretty much the same for other things like rate limiting. It also gives you monitoring for each API, again cutting down on the things you have to add to every single API by encapsulating the function in the gateway.

Also, you can separate your internal API and your external APIs. Maybe you have to always support certain operations to the outside world, but internally you'd really like to change something. By having them separate, you can create a policy within the gateway to change how the internal calls are done without changing the interface as far as the outside world is concerned.

You can also do various types of conversion (e.g. REST->SOAP) or even more exotic things so that outside devs don't have to care just how weird your damned mainframe is or other aspects of your internal architecture that they shouldn't know about.

The target market is, effectively, anyone who wants to expose internal APIs to the outside world.

Source: I work on an API Gateway and this is how our product works.

Let's say you had 10 or so APIs that you wanted to monetise. You might want to bundle these up into groups that you sell. You might want institute different pricing tiers for different rates. To have to bundle all that into each application (along with communicating things like rate usage between them) might not be very appealing.