Post JSON to REST web service with soapUI

Among several web service test tools I have used, including WCFStorm, VS WCF Test Client, and other proprietary test tools, soapUI is my favorite. In a recent project, with the help of soapUI, I was able to add custom fields into HTTP header, compose the authentication header field, and POST JSON data to a REST web service. This post aims to provide a quick guide on how to add REST web services to soapUI and post JSON to the services.

Create a new project.

9-17-2013 11-00-15 AM

Provide a name and select the option Opens dialog to create REST service. Click OK.

9-17-2013 11-01-25 AM

In the next screen, provide the web service’s URL and select the option Extract Resource and Method from specified Endpoint, so that SoapUI can analyze the URL and find out the parameters in it. In my example, Site ID and User ID. Click OK.

9-17-2013 11-03-17 AM

You can define the parameter names and default values on the next screen. Click OK.

9-17-2013 11-07-07 AM

Next you can setup your method, including HTTP method and parameters. We will select POST here to demonstrate how to post JSON.

Click OK to finish creating the method.

9-17-2013 11-08-49 AM

Now we can go ahead to expend our project and method, and select the request just created. On the right pane, our parameters and end point are displayed.

9-17-2013 11-10-19 AM

Next, modify the Media Type to using application/json. There is no such an option in the dropdown list so it has to be typed.

Then type up the JSON you want to post.

Click on the green arrow on the left upper corner of the request. soapUI will post the data to the endpoint.

9-17-2013 11-16-16 AM

Click on the Raw tab to view the raw data just posted!

9-17-2013 11-19-27 AM

As it is demonstrated, soapUI is a very flexible and effective tool which offers a free, quick, and simple solution to test web services.

Mobile Development – Hybrid vs. Native Apps

With the emerging of packaging tools or hybrid app containers such as PhoneGap, a decision has to be made by all companies seeking to develop mobile apps – Hybrid or Native.

First let’s explain the terms here. Hybrid apps refers to mobile applications developed with HTML, CSS, and JavaScript, which are familiar technologies used by many web development companies, and then packaged in a native application container which has access to many device APIs and sensors.

On the other hand, native apps refer to application developed with platform specific SDKs and languages such as Apple’s Object C, Android’s Google API, etc.

Pros and Cons

Hybrid App

Pros:

One code base can be packaged to multiple platforms, including iOS, Android, Windows Phone 8. Note that WP7 does not support HTML5 so this approach won’t work on it.

  • Utilizing popular web technologies to develop
  • Less development effort needed
  • Less support effort needed

Cons:

  • No access to the full device APIs and sensors, but most of them
  • Performance not as good as a native app

Native App

Pros:

  • Access to all the device APIs and sensors
  • Maximized performance

Cons:

Need to develop a separate set of codes for each platform:

  • Knowledge on platform specific language and tools
  • More development efforts
  • More support efforts

Hybrid always wins?

From this comparison, it appears using hybrid approach is always the right approach, unless the app to be developed relies heavily on performance such as a graphic game. However, just like everything else in the universe. There are trade-offs. The extra flexibility and reusability are at the cost of efficiency and effectiveness:

User experiences

Each platform has its own user experience guidelines as the best practice to develop a platform-specific user experience, and users are used to them. Hybrid apps have a unified appearance and work flow across all platforms which would sometimes frustrate users who are not familiar with the user interface presented.

Below are a few styling differences:

  • iOS has its smooth and detail-oriented built-in animations.
  • Windows phone has its large font and menu.
  • Android allows sharing application data with every app installed on the same device.

To list a few work flow differences:

  • iOS uses on-screen touch buttons to go back whereas Android and Windows phone are using on-device back button.
  • Windows phone apps utilize horizontal tabs a lot. When a tab is clicked the page will horizontally scrolls to the page. But iOS and Android do not use this UI element.

Feature differences

Each platform has its unique feature which can’t be utilized through hybrid apps. For example:

  • Android has widgets.
  • WP has live tiles.

Debugging

Performance seems to be not that critical for most of the people, since the hardware has become more and more powerful each day. However, debugging could be a nightmare for hybrid developers – what if an error is caused by the codes generated by the packaging software? Without advanced debugging tool provided for native apps and the knowledge of how the packaging tool works will certainly turn a trivial error into a huge road block.

Conclusion

There are many factors to be considered when making the decision – flexibility, time to market, cost, performance, etc. There is not a one size fits all solution to it. However, if enough resources are available, I will go for native app for sure.  An optimized user experience is a must for an app to be successful. Otherwise, using hybrid is an alternative which can provide a minimized time to market and cost and maximized flexibility and reach.

References

The ups and downs of hybrid mobile app development

Whitepaper mobile developer guidance by Kendo UI