Bookmark and Share


CRest holds an internal registry of per-class serializers for a few common types.

The table below describe the supporter types and their serialization method.

Parameter typeSerialization method
java.util.DateSerialized to yyyy-MM-dd'T'HH:mm:ssZ format. Can be changed through CRestBuilder.dateFormat(java.lang.String)
java.lang.Boolean/booleanSerialized to true/false format. Can be changed through CRestBuilder.booleanFormat(java.lang.String, java.lang.String) content dump content dump content dump

For any other type, the toString() method is used to get it's value.

Any additional type can be added to the list above by providing a custom implementation of the Serializer interface, as follow:

CRest crest = new CRestBuilder()
                    .bindSerializer(SomeTypeSerializer.class, SomeType.class)

Or if this apply only to one specific parameter, by using the @Serializer annotation, as follow:

public interface SomeInterface {

    void doSomething(@QueryParam("value") @Serializer(SomeTypeSerializer.class) SomeType someType);



CRest handleS one-level deep array/collection parameters where, by default, each value is serialized using the rules above and assign to a name/value pair following HTTP standard.

It is common though to interact with service provides that handle array/collection values as a single name/value pair where the value is a character delimited list of values.

In order to address that, one can use the @ListSeparator annotation on an array/collection parameter to change the default serialization behavior and merge values given a string.

The following:

public interface SomeInterface {

    void doSomething(@QueryParam("values") @ListSeparator(",") String... values);



CRest crest = CRest.getInstance();
SomeInterface someInterface =;
someInterface.doSomething("a", "b", "c");

CRest will issue the following request:

GET http://some.server?values=a,b,c

Without the @ListSeparator annotation, the same call would have issued the following request:

GET http://some.server?values=a&values=b&values=c

HTTP Entity

CRest default behavior for HTTP entity writing is to use application/x-www-form-urlencoded encoding format for any entity request (POST/PUT) and multipart/form-data encoding format for multipart requests.

This behavior can be customized by providing a custom EntityWriter interface implementation.

You can find some example on Xml or Json entity writing on the CRest's source repository: Entity writers.

Nota Bene: these entity writer implementations are experimental and are only given as examples.