Mobile developers prefer RESTful APIs: is that a problem for enterprises?

Mobile developers prefer RESTful APIs: is that a problem for enterprises?

Summary: Have a lot of traditional enterprise services? Leave them be, new paper advises.

SHARE:

"Mobile app developers are not going to start developing for SOAP web services. Enterprises are not going to rush to replace massive earlier investments in SOAP even with the advent of mobile apps. Neither side is switching."

That's the conundrum presented in a recent white paper published by the gang at SOA Software, which proposes that there is a happy middle ground in which these two worlds can be brought together.

Much of the enterprise infrastructure that has proliferated over the past decade has been built on SOAP-based web services, which were designed to support enterprise-scale messaging, integration, resiliency, extensibility and security. As mobile interfaces become an even bigger part of the enterprise, there's an urgent need to span the gap between SOAP-based enterprise services and REST.

Many proponents say REST-JSON is the only way to go with mobile app-based services, "because it is smaller and less bloated than SOAP-XML." John Sprunger, writing in a post late last year, agrees that REST-JSON is faster and more effective for mobile app deployments, but for enterprises, the best approach is a big "it depends."

Sprunger outlines the contrasting benefits of the two sets of protocols:

REST/JSON

  • "Faster deserialization, slower serialization (in .NET at least)
  • Smaller message size
  • Easier to consume in Objective-C, Android, and JavaScript (for mobile web apps)
  • Easier to consume for simple web services
  • Preferred choice for public-facing, external web services"

SOAP/XML

  • "Slower deserialization, faster serialization (in .NET at least)
  • Larger message size
  • Easier to consume in .NET-based mobile platforms (Xamarin, Windows Phone)
  • Easier to consume for highly complex web services
  • Preferred choice for private, internal web services"

However, there is a way both worlds can co-exist, the SOA Software paper says -- ensuring that enterprises still benefit from the maturity of SOAP-based web services environments, while taking advantage of the flexibility of REST-based interfaces for a new generation of mobile clients. "The secret is to let everything be. Let SOAP be the application integration powerhouse in the enterprise. Let REST be the dominant mode of interaction in the mobile app world."

Connect "mobile apps with enterprise back end systems is to transform the existing SOAP web service into a RESTful API," the paper advises. "This way, the SOAP service can stay in place, doing what it does, but the mobile app can easily access the data and procedures it needs."

The paper refers to this as "enterprise-to-mobile (E2M)," and is, in effect, all about transforming  SOAP web services as RESTful APIs:

Enterprise developers "would create RESTful APIs for each web service they wanted to make available to mobile apps. The app calls on the RESTful API using an HTTP request, as is the norm for REST. Using special tooling, the RESTful API transforms the HTTP request into a SOAP message that can be parsed by the SOAP web service. The response is then transformed from SOAP to JSON and routed back to the mobile app."

(Thumbnail photo: Joe McKendrick.)

Topics: Web development, Apps, Mobility

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

3 comments
Log in or register to join the discussion
  • SOAP is dead

    Let it rest in peace. It was always too quirky and tighly coupled leading to interoperability and versioning woes.
    dilettante
  • REST has its problems too, and no, SOAP is not dead

    REST has one big problem, and its the difficulties of doing it right on the server end. All of that parameterized virtual pathing has to work... and it doesn't always. Ask anyone who's worked with Microsoft's WebAPI what a pain debugging THAT is.

    SOAP is challenging to bind to when you're not using a Microsoft proxy generator or PHP (which is similarly easy.) God help you trying to figure out creating the proper SOAP envelope from Objective C. So its no panacea to be sure.

    But there are limits to Enterprise IT budgets... SOAP APIs can go up relatively quickly. REST, not so much.
    Mac_PC_FenceSitter
  • I should write papers

    I should write papers because I started doing just that several years ago. It's easy with Java EE applications as you can just add some JAX-RS annotated classes that call the existing SOAP routines and provide any conversion. It can sometimes be tricky because the design patterns tend to be different with the REST developers thinking in nouns and the SOAP developers thinking in verbs.

    As far as SOAP being dead, I wouldn't go that far, but we do tend to consider it legacy code.
    Buster Friendly