search

restfulobjects / restfulobjects-spec

The Restful Objects specification defines a set of RESTful resources, and corresponding JSON representations, for accessing and manipulating a domain object model.
http://restfulobjects.org
73 stars 10 forks source link

RO should define platform-independent primitive types #27

Open abstratt opened 10 years ago

abstratt commented 10 years ago

Property types should not expose the platform specific types used in the implementation. Instead, RO implementations should expose only platform independent types.

Example, from Isis RO viewer:

http://mmyco.co.uk:8180/isis-onlinedemo/restful/domain-types/TODO/properties/description

{ "rel" : "urn:org.restfulobjects:rels/return-type", "href" : "http://mmyco.co.uk:8180/isis-onlinedemo/restful/domain-types/java.lang.String", "method" : "GET", "type" : "application/json;profile=\"urn:org.restfulobjects:repr-types/domain-type\"" }

danhaywood commented 10 years ago

Thanks, Rafael... I agree. Will look to update in a future version of the spec.

darabi commented 9 years ago

I just started the simpleapp demo and was very surprised to find java.lang.String. How does the viewer deal with this? Does it support one string type for dot-net and one for Java?

abstratt commented 9 years ago

@darabi You can still look at a RO type called 'java.lang.String' and interpret it in a way that makes sense in your implementation platform. IMO, this ticket is more an issue of aesthetics than anything.

darabi commented 9 years ago

From one perspective, yes. But it becomes problematic when I want to implement the spec in another language than Java.

And even if I just wanted to consume the API: as the number of implementations grows, would I have to write conditionals for half a dozen of different primitive types for different languages for being able to consume a string literal correctly?

danhaywood commented 9 years ago

Nice to see this conversation going on.

When I wrote the spec I did do quite a lot of thinking about datatypes, and there's a discussion about them in section 2.5 of the spec (v1.0). So actually, it's probably correct to say that this is an error in the implementation, but the spec has you covered. So if you want to go ahead and write a different implementation, you can.

If you weren't aware, there is actually another implementation of the RO spec, namely by the Naked Objects framework. So it's certainly "do-able".

abstratt commented 9 years ago

@darabi Right, with multiple server implementations, you need to be able to handle both correct 'string' and the incorrect 'java.lang.String' type ids, which is indeed a pain.