The Restful Objects specification defines a set of RESTful resources, and corresponding JSON representations, for accessing and manipulating a domain object model.
Two solutions (within the current spec) come to mind
the value in all ways is presented and set as a string.
Present the value as the correct underlying integral type with the choices as the set of possible integral underlying values.
I'm not keen on 1.
It doesn't fit with the existing model from MVC where we use the underlying type and the enum 'name' is just a presentation hint for the UI.
It's possible (certainly in .net) for an enum to have an integral value that doesn't map to a string representation.
If we have a more sophisticated way of supporting enums in a later spec this is not backwards compatible.
Concealing the underlying type like this 'feels' wrong and will create lots of nasty special cases in the code.
However 2. for the moment means that enums don't really add any value (just the set of possible values).
I would propose to do 2. now but ask for some explicit support in the next version of the spec.
eg how about something in the extensions (and formal types) which contains 'display hints' and a map
(eg {{"Male : 0}, {"Female" : 1}}) which would allow a client to display the value and choices in a friendly way but
send and receive the underlying type.
ver: 1.0.0 raisedby: stefcascarini
ref: http://restfulobjects.codeplex.com/workitem/30
Two solutions (within the current spec) come to mind
I'm not keen on 1.
However 2. for the moment means that enums don't really add any value (just the set of possible values).
I would propose to do 2. now but ask for some explicit support in the next version of the spec.
eg how about something in the extensions (and formal types) which contains 'display hints' and a map (eg {{"Male : 0}, {"Female" : 1}}) which would allow a client to display the value and choices in a friendly way but send and receive the underlying type.