#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?