The other day I had to figure out a way to compare two different web services to see whether a subset of their outputs were equal or not. One of these services (let’s call it the legacy service) is capable of emitting XML as a response, while the other one (a completely new service that is intended to be a replacement for the legacy code) uses JSON. Unfortunately, the output of these two are only similar in a conceptual way: their structures differ a lot, and they use very different ways of structuring data.
I checked out some common frameworks for testing web services, and though all of them were useful for parts of my task, they proved to be hard to use for my complete work. Of course, all these frameworks are too general purpose, while my problem is, I guess, not that of a common use case. At this time I started experimenting with REST Assured – a framework that finally saved me a lot of time and effort. In the below post I will describe how easy it was to get my job done in a relatively short time with this cool framework.
First of all, as I mentioned: the hard part of this task was not the inherent difference between XML and JSON, there are really good tools to overcome this issue. The problem was that the logic by which the two services structured their responses was completely different: same data, different representation. To make things just a little bit worse, the new endpoint is communicating in a secure manner, through https.
I’m not going to share the exact details of the two responses, but the below code represents a simplified (and modified) version of the outputs. First, the legacy XML output:
And now, the JSON variant:
As you can see why the XML document is country-centric, the JSON response takes a different view and puts providers as top level elements.
As JSON is really easy to parse using Jackson, I decided to start with this part and stick to its structure for my model objects (the only data I needed was the provider ID and country IDs for that provider). I was more than happy to see that REST Assured has a way of ignoring https validations, so I didn’t need to create and use self-signed certificates and keystores. This way, it was really easy and convenient to call the service, parse and convert the response, and have the fields I was interested in (less than 50 lines of code):
Note the relaxedHTTPSValidation() method call in the given() clause.
The first part was ready, but I still needed to extract the data from XML and convert the result to the same format as in the first case. At the beginning, I was thinking about using JAXB for parsing and a custom converter to translate the resulting objects to the format I picked earlier.
Luckily enough, I did not need to do that. REST Assured already has another great feature for efficient data acquisition from XML documents, called XmlPath. One can feed XmlPath with Groovy expressions for efficient data retrieval; this makes it really powerful and easy to understand at the same time. In order to get the data I needed out of the XML document, I only had to use this much code:
As I am not a Groovy guru, I needed to ask for help. Fortunately, I got it pretty fast here. A quick explanation for the fellow Groovy novices: the first query (ALL_PROVIDER_IDS_QUERY) selects all the provider IDs from the whole XML document and returns them in a list. The second one (COUNTRY_IDS_BY_PROVIDER_QUERY) extracts all the country codes for a specific provider. Unbelievable, but even easier than JSON parsing.
The only thing left was to write a good equals method inside Provider and I was done. I really think REST Assured is an awesome tool that can save a lot of time and effort. It’s worth giving it a try next time you need to test web services.
Join the DZone community and get the full member experience.Join For Free
Establish API creation, publishing and discovery as a master practice with the API Management Playbook.
Apache CXF vs. Apache AXIS vs. Spring WS
Apache CXF vs. Apache AXIS vs. Spring WS
This blog does not try to compare all available Web Services Development Frameworks but focuses only on three popular approaches
This blog does not try to compare all available Web Services Development Frameworks but focuses only on three popular approaches regarding three Open Source frameworks: Apache CXF, Apache AXIS & Spring WS.
❶ Most Commonly Used, Matured & Stable Web Services Development Framework
❷ Supports Multiple Languages (C++, Java)
❸ Supports both Contract-first & Contract-last Approach
❹ In context of Orchestration & Web Services Transaction (long-running transactions) it supports wide variety of related WS-* specifications:
WS-Atomic Transaction, WS-Business Activity, WS-Coordination, WS-Eventing, WS-Transfer
Compatible with Spring Framework
❶ Comparatively More Code Required/Generated w.r.t. Spring WS/CXF
❷ Is being phased out gradually (mostly by Apache CXF)
❸ It is not fully compliant for JAX-WS JAX-RS
❶ Most widely used Web Services Standard Now; Improvement over AXIS2, which is now gradually being replaced by Apache CXF
❷ Intuitive & Easy to Use (less coding required as compared to AXIS2)
❸ Clean separation of front-ends, like JAX-WS, from the core code
❹ Fully compliant with JAX-WS, JAX-RS & others
❺ Best Performance across all available framework with minimum computation overhead
❻ Supports wide variety of front-end models
❼ Supports both JAX-WS & JAX-RS (for Restful Services)
❽ Supports JBI & SDO (not supported in AXIS2)
❾ Compatible with Spring Framework
❶ Does not support Orchestration & WS Transactions yet
❷ Does not support WSDL 2.0 yet
❶ Best in terms of supporting Contract-first Web Services Development Approach
❷ Enforces Standards & Best Practices by Framework Constraints (no way out of it & hence limitation as well)
❸ Supports Spring Annotations as well as JAX-WS
❹ Least code from developer’s perspective
❺ Best Aligned with Spring Technology Stack (also similar architectural stack as Spring MVC) including Spring Security
❶ Least number of WS-* Specifications supported (does not fully compliant with JAX-WS)
❷ Spring offers itself as standard & hence other Java-compliant frameworks support better standards support
❸ Only support Contract-first Web Services Development Model
- Apache AXIS2 is relatively most used framework but Apache CXF scores over other Web Services Framework comparatively considering ease of development, current industry trend, performance, overall scorecard and other features (unless there is Web Services Orchestration support is explicitly needed, which is not required here)
- Though Spring Core Framework is an established technology, Spring Web Services is still evolving in comparison with Apache CXF and CXF has wider support of standards and proven framework from performance perspective.
- Hence, Apache CXF is the recommended framework and clearly the most preferred in my opinion.
All data and information provided on this site is for informational purposes only. This site makes no representations as to accuracy, completeness, correctness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.This is a personal weblog. The opinions expressed here represent my own and not those of my employer or any other organization.