Hacker News Reader

Comment by jively | Hacker News Reader

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.

View on HN

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

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.

"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.

API Tellum?

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.

do you have a website?

Not really, why do you ask?

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

Gateway, under oracle branding.

May God have mercy on your soul :o)

;_;

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.

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

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".

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

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

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.

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

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.

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

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.

Reply on news.ycombinator.com