News Stay informed about the latest enterprise technology news and product updates.

Session Coverage: Mobile App Integration – Why is it Different?

This is part of a series covering sessions at Oracle OpenWorld and JavaOne, 2015

Any mobile app needs to integrate with back-end services, as pointed out by Joe Huang, a solution architect at Oracle, at the beginning of this Oracle OpenWorld 2015 session on integrating mobile applications. These are hardly shocking words to any seasoned developer, of course, but the manner in how they approach this integration is essential to success with mobile apps.

According to Lyudmil Pelov, product manager at Oracle, the key to integrating mobile apps successfully is learning to create Representational State Transfer (REST) APIs.

“REST rules the cloud,” said Peylov. “Today there is not modern cloud without REST.”

Pelov began his presentation by laying out a comprehensive comparison of REST versus the more familiar Simple Object Access Protocol (SOAP), pointing out some of the following key facts:

  • REST is a software architecture style consisting of guidelines and a few best practices, while SOAP is protocol specification for exchanging structure information.
  • REST typically uses HTTP as a transfer protocol, but it can be built on others.
  • REST makes resources available as “nouns” (ie. “users” or “items”), while SOAP treats them as services (ie. “getUsers” or “getItems”).
  • REST separates client-server communications clearly, while SOAP communicates information about the object to the client (an approach most enterprises like due to security)
  • SOAP implements security and authorization as part of the protocol, while REST makes it difficult to enforce security and authorization.
  • SOAP is heavier to implement and requires heavy bandwidth communication

So when do you choose which one to use? Pelov suggests that REST should be used when there is limited bandwidth, it is not necessary to communicate object information and when you want APIs that are easy to use and implement. SOAP should be used when the client requires access to objects on the server, if you are performing transactions with multiple calls, or if you are faced with a strict client-server communication contract.

Beyond this point, the session focused solely on REST APIs, so anyone who had decided at this point that they need to use SOAP would not get much out of the remainder of this session. However, Pelov did have some strong advice for the use of REST APIs.

First, Pelov laid out the seven key principles of REST: performance, scalability, simplicity, modifiability, visibility, portability and reliability. He pointed out that REST APIs absolutely must be intuitive, consistent, flexible and simple.

Another topic Pelov delved into was the HTTP protocol limitations that affect REST APIs. These included the following:

  • When using a GET operation, there is a limitation to the amount of data you can send in one pass in certain browsers.
  • Browsers can handle only specific amounts of GET requests at the same time, including all the resources that should be loaded onto the page. For example, Firefox will allow six while Internet Explorer 10 will allow eight. He also pointed out that HTTP 1.1 only allows 2.
  • Again, when it comes to a GET, URL parameters are not as flexible or expressive like JSON or XML
  • POST is not an idempotent operation and is not safe. If it fails, you need to find out why immediately.

Pelov then went into a discussion on HTTP REST API code responses, including the following:

  • 2xx means success
  • 3xx (specifically 304) is used when in browser cache
  • 4xx indicates an associate client error
  • 5xx indicates a critical error on the client side

When do you use 4xx and 5xx responses? Pelov explained that 4xx should be used to tell the client that a fault has taken place on their side, and they should not retransmit the same request again without fixing the error. He said that a 5xx response indicates to the client that something happened on the server, but that the request was still valid, and that the client can continue and try again later with the same request without modification.

In conclusion, Pelov laid out the following rules for using REST:

  • Do NOT implement specifications in the API.
  • Do NOT implement functionality which should not be part of the backend.
  • Use ONLY standardized methods.
  • Make sure that a secure sockets layer (SSL) is in place if there is sensitive information involved
  • Do NOT implement your own authentication methods.
  • And, finally, the best API is the documented

So what did attendees think of the session?

“There are various new technologies coming, so there was a lot of comparison with on-premise, with the cloud…and they explained those very well,” said Pandurang Ranjalkur, the practice head of Oracle Fusion Middleware at L&T Infotech, a global IT services company based in Mumbai, India.

Ranjalkur, whose company designs mobile applications for clients such as Samsung, says that his biggest challenges surround mobile development and the use of REST revolves heavily around security, among other factors.

“Security needs to be considered very important,” said Ranjalkur, who noted that too often the security in place is simply too weak. And in terms of working with REST itself, he said that “scalability and security and performance are the key REST problems.”

Lyudmil Peylov of Oracle explains the advantages of REST and SOAP

Lyudmil Pelov of Oracle explains the advantages of REST and SOAP.

Explaining when to use each.

Explaining when to use each.

Final words on using REST.

Final words on using REST.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close