Quite a simple problem but unsure of the right solution here so looking for some community experience to help out.
I have a static website that needs to interact with a soap service, which only supports XML responses. This service will take a form post request and return a simple respone which needs to be parsed and displayed to the user.
To make things easier for our development team and to also protect the soap service we plan to run the request through an API gateway to proxy the request.
Since we are going to proxy it makes sense that we make things simple for the developers by providing an interface at the gateway that allows json requests and responses rather than having to work with XML schemas, we will also convert the soap service to appear as a rest service at the gateway for clients wishing to access.
At the moment we have two cloud platforms AWS and Google. I know that AWS API gateway can handle mapping and data transformations along with lambda functions to do further heavy lifting, however I'm unsure whether it has any support for soap transformation in the manner I've discussed.
To summarise questions I have left open:
Has anyone done this before and has some pointers?
I'm completely unconvinced whether Google can do this, using their endpoints platform and I assume compute functions. Can anyone clarify or confirm? It seems to be quite a basic capability still.
Any guides/tutorials available? It would be good to walk through the work involved.
Help is appreciated 👍
Top comments (1)
This is not as simple as it seems at first sight: both - rest and soap are ways to abstract apis. But(!) while rest follows a common schema, soap has no restrictions at all. In rest you take resources and offer always the same services for it. Let's say you have a user, then you offer
The names of the methods are a convention and every rest api is build around this scheme.
A soap service has none of this conventions, so you could (and will) find all kind of functions and function-arguments. And this functions are not necessarily arranged around a single resource.
What I want to say is that it is not a question of mapping function names and arguments from xml to json - it is much, much more and even for small services very complicated and almost unmaintainable. If you decide for one of this approaches, stick with it.