Should I push for proxy REST/JSON even if target is SOAP/XML?

[vinhpham95]

Target expects SOAP/XML. Source can do REST/JSON or SOAP/XML. Should I tell Source to call REST/JSON and transform payload into SOAP/XML via. Apigee, or should I just tell Source to keep it SOAP/XML for consistency?

Based on Best Practices, REST/JSON is the ideal solution for (most) Proxies. However, does this still apply if target has a requirement for SOAP/XML - that is, if the target application expects SOAP/XML, should I still ask the source to send me via. REST/JSON?

[nagashree_b · Accepted solution]

You said it all!

Based on Best Practices, REST/JSON is the ideal solution for (most) Proxies.

Its is ideal to have the consumer of your API make a REST call with JSON if you are undergoing a modernization exercise. However if you see some resistence to change from the consumers, you could start off with supporting both XML and JSON by branching out the logic using the content-type header and send the responses in appropriate format based on the Accept header in the request.

You could run it this way for sometime (or even indefinite) and then have a newer version mandate REST/JSON.

[dchiesa1]

I would say "think outside in"

If the developers using your exposed APIs will use a set of APIs, then ... produce the easiest-to-use set of APIs you can. If "easy" to them means REST and JSON, do that.

It's probably an anti-pattern to force consuming developers to use both REST/JSON as well as SOAP within a single set of APIs. Forcing them to learn two different models is cruel.

On the other hand there may be some audiences of developers that prefer a SOAP interface, with WSDL. Sure it's old, but maybe it works well with their existing toolchain. So in that case, you may want to allow the developers to continue to use SOAP, even if Apigee Edge is proxying the APIs. In fact I have seen a company build a "reverse" RESt-to-SOAP proxy in which the upstream is REST, but they exposed it as a SOAP interface for a subset of their developers who were not ready to abandon SOAP and WSDL.

In short, think of the consumer developer, and try to do what is best and easiest for them.