Stable legacy systems are great. They are reliable and usually predictable. SOAP services have been a staple in the enterprise for many years and can make up a large share of web-enabled enterprise applications.
There are plenty of benefits to SOAP web services, from using WSDL documents to create well-defined schemas to the maturity of using a protocol that has been around since the late 90s. As web-based technologies grew during the 2000s, SOAP was the go-to standard for web services. This has left us with a long lineage of legacy applications within the enterprise. These are now becoming outdated, with their XML interfaces being challenged by modern, JSON-driven applications.
Unfortunately, this means that modern web apps that rely on JSON for requests now need workarounds to utilise the XML-dependent SOAP services that house the data they require. From this need we can derive many solutions, including:
- Rewrite the services as RESTful services.
- This is costly and risky. You may need to maintain the current SOAP web service and build the new RESTful API(s) required so that other apps won’t be forced to move to use the RESTful interface. It also means new code and infrastructure builds. This may then lead to refactoring upstream and downstream applications that are coupled with the SOAP service if you decide not to decommission it and move strictly to using the RESTful interface.
- Create a service with a RESTful interface that will transform your incoming JSON request into XML, forward to the SOAP web service, and transform the XML back into JSON upon response.
- This requires code and infrastructure specifically for this purpose. It means you now have a new application with its own support and maintenance needs. This requires developers to code, and a fair amount of work if you need to add new endpoints.
- Use the front-end code to handle SOAP requests and responses.
- Most modern web applications and frameworks run on JSON, so this will take time and include some custom code to transform the application’s JSON data into XML requests (and the corresponding response). This will probably mean that you’ll be building a transformation service into your code. That will then require updates, with corresponding regression testing and deployments leading to higher spend for minimal value. This means that your modern web application now has legacy baked in with the addition of a transformation layer. This is not optimal.
Each of these options has a fair share of work and maintenance associated with it, along with associated project planning and costs. In the enterprise, even the smallest technical projects aren’t cheap!
So, is there another way to add JSON-supported endpoints within SOAP services in your stack while limiting code and infrastructure changes? With Tyk, there is.
Tyk can transform incoming and outgoing traffic, including transformations to the body and header of requests and responses. This functionality is comprehensive and you can customise it based on different needs. By default, you can specify that you would like a transformation to occur. You can use the pre-defined JSON to XML logic to transform your incoming request, and the pre-defined XML to JSON to transform your outgoing responses accordingly.
With this functionality, Tyk provides a one-to-one mapping of your JSON object into XML or vice versa. If more advanced transformations need to take place, you can use a Golang template to customise transformation logic. Using the Tyk Dashboard makes this even easier. It supplies an intuitive UI which allows you to edit and view your input, template, and the output of the transformation.
Technically, using the dashboard to create these transformations means:
- exposing your SOAP services with JSON interfaces requires no code
- no infrastructure changes are required for your services
- your existing SOAP web service functionality is still in place for existing consumers of the service with no changes
These new endpoints can be fully functional within minutes. They are easily changeable, so you can significantly reduce project costs from the web service side. In addition, new consumers requiring JSON functionality can begin using your service quickly (and reliably, since you’re still using your existing and stable SOAP web service for all the logic!).
You can set up this functionality in just a few simple steps with the Tyk Dashboard:
- Create the endpoint that points to your SOAP web service (you can do this by importing a WSDL file)
- In the Endpoint Designer for your SOAP-based endpoint, add the Body Transform plugin
- With the Body Transform plugin enabled, customise your request and response transformations as needed
- Publish your API! A live and ready-to-use endpoint is now available to consumers who require JSON functionality
Using Tyk to enable rapid development of JSON APIs that utilise existing SOAP services is an impressive way to expand functionality and keep the integrity of the existing system’s logic and infrastructure, while not changing anything for existing consumers. In the enterprise, we are often faced with extensive projects and tight deadlines for these types of changes. With Tyk, however, we can forgo many of these challenges. Tasks such as rewriting an entirely stable SOAP web service to a JSON interface can be undertaken quickly, leaving time and budget available for more valuable work. Expanding your API offering has never been easier.