Roy T. Fielding wrote:
> On Dec 4, 2007, at 2:00 AM, Liu, Jervis wrote:
>> I think we do need to support " int someMethod ()", this make it a lot
>> easier when people migrating their existing code to JSR-311. For
>> example, I may have following method in my POJO, it is just a matter
>> of adding extra JSR-311 annotations then I can expose this POJO as a
>> RESTful service.
>>
>> int getEmployeeAge(String employeeName) {
>> ...
>> }
>
> No, that would be encouraging folks to migrate one crappy design
> to another -- it has nothing to do with being RESTful. There is no
> way to "migrate" a POJO design to a RESTful design without completely
> redesigning the service. That is, in fact, the entire point -- design
> the service so that it matches the reality of network-based applications
> instead of doing RPC in yet another inefficient syntax.
>
Right.
I would like to point out that the signatures of HTTP Java methods are
not as significant or "fixed in stone" (they don't affect the uniform
interface). This means it is much easier to change the service
implementation without breaking clients, so i, putting the caveats on
returning such information aside, could have the any the following:
int get() { return 1; }
Integer get() { return 1; }
BigInteger get() { return new BigInteger("1"); }
String get() { return "1"; }
Response get() { return Response.ok(new Integer(1)).build(); }
but from the client the representation returned by the GET request is
the same.
I think this stresses the importance of test driven development so not
only should the service developer know what goes on the wire it should
also be tested to ensure that is the case.
I am mostly ambivalent about having runtime support for representations
generated from primitive types as they can be converted to String with
minimal fuss and the developer is likely to know better what is going on
the wire in such cases (i get scared when XSD gets involved!!, even if
it is for the data types as it tends to obfuscate).
IMHO of more importance is support for URI. I see that as a more common
case and it is clear what the on-wire representation should be.
Paul.
> ....Roy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109