Prerequisites and Limitations for Writing REST Applications
Before development, it is important to understand the prerequisites and limitations of the GemFire REST implementation.
GemFire and REST-enabled applications accessing GemFire are subject to the following rules and limitations:
- All domain objects, functions and function-arg classes must be properly configured and registered in the GemFire deployment. Any functions that you wish to execute through the REST API must be available on the target member’s CLASSPATH.
- The current implementation supports only the application/json MIME type. Other return types (XML, objects, and so on) are not supported. Plain text is supported as a return type for some error messages.
- Keys are strictly of type String. For example, the request
PUT http://localhost:8080/gemfire-api/v1/customers/123.456 will add an entry for key (“123.456”) of type String.
- Some special formats of JSON documents are not supported in GemFire REST. See Key Types and JSON Support for examples.
- To achieve interoperability between GemFire Java clients (or GemFire native clients) and REST clients, the following rules must be followed:
- All GemFire Java and native client classes operating on data also accessed by the REST interface must be PDX serialized, either via PDX autoserialization or by implementing
- GemFire Java clients and native clients can retrieve REST-enabled data either as a
PdxInstance or as an actual object by using the
PdxInstance.getObject method. If you use the latter method, you must first declare the object type (@type) in your POST or PUT request payload when creating the object in REST; and secondly, the Java client must have the actual domain class in its CLASSPATH.
- Objects returned by REST-invoked functions must be returned as PdxInstance objects or other data types that can be written to JSON. You cannot return Java objects.
- REST client applications do not support single hop access or notification features.
- Specifying subregions as endpoints is not supported.