Applications are written in diverse and often remote environments. Storing and accessing data needs to be simple and portable, which is why REST (representational state transfer) is often the go-to protocol for web services.

And yet, using REST for data services can pose a number of challenges:

• Performance (clients should be able to quickly access data and serve as many clients as possible. The packet should be efficient and small)
• Query Semantics (there needs to be a simple and uniform interface that is acceptable on REST)
• Support for Portable and Unstructured Data Formats (Documents)

Re-Thinking REST

As such, REST is best used in conjunction with other protocols. For low-latency access, the native protocol can be used, and for other cases, REST can be used.

Let's say that you have a client and a server. You want them to communicate. Usually, every server provides an API that the client can use to get rid of excess data on the server. If it's Java, it will use a protocol that is native to Java, and it will likely not use REST — the native protocol will likely be faster.

Some applications use more than one source for their data, however. One could provide the Java API and another one will have another API. When all of these APIs can use REST, it makes things easier on the developer because it is all one uniform protocol. REST is an easy protocol that can work on any platform.

Going Mobile

Most mobile web service applications are remote, and performance is handled in other forms such as batching or remoting. The client is the mobile application, and the server is located in another country or across the world.

Accessing the REST API on the server side is called the remote. Instead of sending one JSON (object) at a time, you then have the ability to send a collection of objects so that the server can handle it all together. You are able to execute a remote task, which you can define in your application, and you can send it to the server so that the server executes the entire task.

Data as a Service with XAP

Here at GigaSpaces, we designed the REST interface with XAP so that REST can be deployed with XAP. Through XAP, the REST service can accept JSON formats. XAP also has "documents" (a Java object/key value), which are dynamic, meaning that you can add dynamic properties so that the REST API can accept documents.

Take XAP for a spin!

Let’s take a look at the code:

Request Schema:

 “idProperty”: { //required
    “propertyName”: “id”,
    “autoGenerated”: true, // optional
    “indexType”: “BASIC” // optional, use with autoGenerate. SEE com.gigaspaces.metadata.index.SpaceIndexType
    “routingProperty”: {
        “propertyName”: “id”,
        “indexType”: “BASIC” // optional. SEE com.gigaspaces.metadata.index.SpaceIndexType
        “fixedProperties”: [
        “propertyName”: “id”,
        “propertyType”: “int32” // predefined types or full Java class path*
        “propertyName”: “prop1”,
        “propertyType”: “string”, // predefined types or full Java class path*
        “documentSupport”: “DEFAULT” // optional. SEE com.gigaspaces.metadata.SpaceDocumentSupport
        “propertyName”: “prop2”,
        “propertyType”: “java.util.Map”, // predefined types or full Java class path*
        “documentSupport”: “DEFAULT”, // optional. SEE com.gigaspaces.metadata.SpaceDocumentSupport
        “storageType”: “DEFAULT” // optional, use with documentSupport. SEE com.gigaspaces.metadata.StorageType
        “propertyName”: “indexedProp”,
        “propertyType”: “string”, // predefined types or full Java class path*
        “indexType”: “BASIC”, // optional. SEE com.gigaspaces.metadata.index.SpaceIndexType
        “uniqueIndex”: true // optional, must be used with indexType field only. Default to false.
        “compoundIndex”: {
            “paths”: [
            “prop1”,
            “prop2”
            “unique”: true // optional
            “fifoSupport”: “DEFAULT”, // SEE com.gigaspaces.annotation.pojo.FifoSupport
            “blobStoreEnabled”: true,
            “storageType”: “DEFAULT”, // SEE com.gigaspaces.metadata.StorageType
            “supportsOptimisticLocking”: true,
            “supportsDynamicProperties”: false // optional, default to true

Response Schema:

   "status":"success"

Examples:

curl -XPOST -H "Content-Type: application/json" -d '{"id":1, "name":"myName", "age":10}’ http://localhost:8080/MyObject

Response Schema:

   "status":"success"

Examples:

curl -XPOST -H "Content-Type: application/json" -d '[{"id":2, "name":"John", "age":16},

{"id":3, "name":"Michael", "age":18}]' http://localhost:8080/MyObject

Using XAP with REST

Deploying XAP with the REST interface means that there is support for non-Java and .Net clients. It supports mobile apps, and it provides support for remote apps that are running outside of the firewall. Finally, other apps can be easily integrated. Data can be seamlessly exchanged, and the REST API makes XAP usable with modern microservices and cloud-native apps.