5 Web Services in Retail Applications

Retailers can access backend functionality in Retail Applications by calling the applications' ReSTful Web Services.Refer to http://www.oracle.com/technetwork/articles/javase/index-137171.html to learn more about ReST as an architectural style applied to building web services.

Common Characteristics of Retail Application ReSTful Web Services

This section describes the common characteristics.

Deployment

A Retail Application will package its ReST services as part of the application's Enterprise Archive (EAR) file. Specifically, those services are packaged as a Web Archive (WAR) within the EAR.

Installation of the ReST web services is therefore done by default.

Security

Services are secured using J2EE-based security model.

Realm-based User Authentication. This verifies users through an underlying realm. The username and password is passed using Http Basic authentication.
Role-based Authorization. This assigns users to roles, which in turn are granted or restricted access to resources/services. The authorization of ReSTful web services is static and cannot be reassigned to other rules post installation. The following role(s) is/are associated with ReSTful Web Services and should be added to the Enterprise LDAP:

All enterprise roles defined above are mapped in web.xml and weblogic.xml of the ReST Service webapp.

The communication between the server and client is encrypted using one way SSL. In non-SSL environments the encoding defaults to BASE-64 so it is highly recommended that these ReST services are configured to be used in production environments secured with SSL connections.

Standard Request and Response Headers

Retail Application ReSTful web services have the following standard HTTP headers:

Accept: application/xml or application/JSON
Accept-Version: 15.0 (service version number)
Accept-Language: en-US,en;q=0.8
Accept-Versioning: False

Note:

Specify 'Accept-Versioning: False' in the Service Request to bypass 'Accept-Version' validation on services.

Depending on the type of the operation or HTTP method, the corresponding response header is updated in the Http response with the following codes:

GET/READ : 200
PUT/CREATE : 201 created
POST/UPDATE : 204
DELETE : 204

Standard Error Response

Example response payload in case of service error is depicted below:

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <messagesRDOes>
  <messagesRDO>
    <message>REST Service Version Mismatch</message>
    <messageType>ERROR</messageType>
    <status>BAD_REQUEST</status> 
  </messagesRDO>
 </messagesRDOes>

message: The error message - translated.
messageType: Value of 'ERROR' is returned.
status : For a bad request or error, the status is BAD_REQUEST.
The http error code for an error response is 400.