API proxy over legacy services

We have lot of legacy service end points either plain XML or SOAP or non-open API Compliant API. I want to understand having KONG as API gateway/management tool, how much of transformation capability basically can it support:

  1. XML to Open API compliant request/response transformation
  2. SOAP to Open API compliant request/response transformation
  3. Non-open API compliant to Open API compliant request/response transformation

I don’t see any transformation plugins like XSLT template etc.
Please suggest if it is on roadmap?

Community member here,

I believe for Enterprise they offer something that supports SOAP inbound to REST backend(or maybe I am mixing that up hah, could be REST inbound to SOAP backend?? They can clarify). But nothing like what you are mentioning has been done in the community as of yet, nor do I believe SOAP support is really on the road map as its generally viewed across most companies as a deprecated legacy API(with most moving towards REST).

I personally to have some interest in slight SOAP support(internal legacy api’s that won’t die/stubborn consumers and api providers), but before I write any code I am personally within my Org talking to SOAP providers to figure out a few things:

  1. What can the “client” do, what are their restrictions around SOAP, do they have to use WS-Security or are they flexible.

  2. What can the api provider currently on SOAP do, are their SOAP services exposed through some black box vendor product(in some cases yes, yuck!). Or are they flexible Java based or other lang based coded APIs. If so great we may be able to work with that!

  3. Reason for SOAP, can you move to REST? If no will continue my ideas.

So at this step after I have finished that I have a few ideas and plugins I am toying with in my head:

  1. This requires basically no change, can your SOAP service behave like a REST with POST and backend SOAP service as well? This means can your client just add an OAuth2 Bearer token header or JWT Header for client validation on the SOAP POST call. Then can the SOAP API provider parse and validate that Client header representing the consumer for their Auth.

  2. Can they do the same as above, or possibly inspect the SOAP Headers for such values if Rest Headers are not feasible(a little more work, some xml parse/injection but totally feasible and just leverage a lot existing kong code!). If so I would be fine with this method too.

  3. Literally code the WS-Security Pattern into Kong, really don’t wanna do this, not a fan. Can do if I must but hoping convo tends to modernize the SOAP behavior a bit if they can’t do away with it entirely.

Sorry if that was long winded but its just my initial thoughts and insights so far at the whole thing :slight_smile:

Cheers,
Jeremy

Thanks Jeremy for response, SOAP interfaces in my org is mainly due to legacy reasons, transitioning to REST will take its own sweet time. Besides this there are many platforms used to implement API provider in my org does not support OPEN API standard. I see KONG or an API Gateway solution in 2 ways: one to implement common concerns like security, logging, rate-limiting at single place and second to provide capability to do “API Proxy” over legacy end points in order to standardize the API contract across enterprise…looking at response above, does it mean that KONG is not primarily meant for “API proxy”??

Hi All,
Kong (the company) does not currently offer any features that specifically help with SOAP to REST or REST to SOAP translations. Instead, we advise users with such needs to consider a custom plugin. Custom plugins are developed both by our users and by Kong, under contract with our customers.

On your question about Open API compliance - I don’t really see that as a Kong API Gateway concern. OpenAPI Spec (OAS) and Swagger are formats for documenting APIs. OAS is not really something, in understanding, that a transformation could be “compliant” with. Instead, you could use OAS to document the behavior of an API, and you could then use that OAS to test that your XML/SOAP/REST conversions are working as expected.

Do note, however, that the Kong Dev Portal of Kong Enterprise Edition takes OAS/Swagger as an input, and produces Developer-friendly portal for learning APIs, managing credentials, etc.

Does KONG supports any REST to REST transformation basically I want to mask/revise some of HTTP error codes and error payload which I am receiving from API Endpoint (upstream service)…Response Transformer plugin does not seem to fit here…I would need perhaps something like if-else condition type logic