Does Kong support SOAP/XML-RPC ?

[angusfz]

Hi All,
We have many internal SOAP/XML-RPC web-service, and need Kong to expose such APIs.
Does Kong can support SOAP base web-service ? or just support REST ?

Any suggestion will be appreciated !!

[sonicaghi]

Hi - we have a plugin SOAP-to-REST in the making, but it's commercial. It will be available behind enterprise subscription.

What's your use case?

[petrdvorak]

The use case is publishing SOAP, not REST services via the Kong platform. No conversion to REST. Just using SOAP. Is it possible to achieve?

[sonicaghi]

Hi @petrdvorak not in the near future. The standard pattern is to use an API Gateway for REST and if you really need some SOAP support then you can use Kong/etc to do some light transformations from SOAP-to-REST. But using an API Gateway for plain SOAP is the wrong approach or just the wrong tool for the job.

For those legacy technologies the best approach is to use an ESB or similar middle-wares and keep the API Gateway lightweight just for REST but definitely not worth mixing the two (Gateway <-> ESB) or you will end up with an heavyweight jack of all trades, master of none.

[petrdvorak]

I agree - I had this request from a customer and so I Googled if something like that exists in today's API managements. So far, it seems that the only tool of capable of publishing SOAP services alongside the REST is IBM API Management:

http://www.ibm.com/support/knowledgecenter/SSWHYP_4.0.0/com.ibm.apimgmt.apionprem.doc/config_api_soap.html

In any case, I totally get your argument. IMO people should invest in moving SOAP to REST rather than use a new system (like API Management) to support old technologies.

Just to add one extra note: There is a time and place for SOAP even in today's world and it's internal system integration. The SOAP support provided by for example Spring WS is way more developer friendly than what we can recall from couple years ago with technologies as Axis etc.

[thibaultcha]

In the end, Kong is a transparent HTTP proxy. If your SOAP services run over HTTP, then Kong can carry them just fine. It's just that none of its plugins are written for SOAP communication. As always, you can easily hop into the request/response lifecycle with a custom plugin to do any logic you deem necessary.

[petrdvorak]

Thank you, @thibaultcha - this will likely be the approach we will take here. IMO the customer requirements are non-sensical: One of them is having a "switch" that will make the REST service SOAP and vice-versa. How does this play out with security (OAuth2 for REST vs. X509 certificates for SOAP), logging (individual endpoints vs. all methods on one endpoint) or scaling? ... they don't say...

[mdan1eli]

There are 3 possible scenarios and I think both @thibaultcha and @sinzone are right.

1. expose an existing SOAP WS as REST API => put a lightweight integration in front (e.g. Camel) and keep gateway simple => Kong + Camel

2. enforce some basic policies (e.g. Request size limit or rate limiting) => with API gateway working at HTTP level, but not a full SOA Gateway => we see this for some internal scenarios where we can inject with WS handlers some behavior in our clients=> Kong

3. implement a SOA Gateway, with features like XML payload validation and protection, support for WS-Sec authentication mechanisms for external WS => we are using a different and expensive appliance for this, but could actually be addressed by plugins (security and wire-speed come to my mind as critical parts)

[thibaultcha]

I think the question has been answered.