RE: ServerResource conditional mode

[Jerome Louvel]

Hi David(s),

The Atom extension currently provides support for Atom and AtomPub
representations (Feed and Service classes are deriving SaxRepresentation).

For a more complete server-side support of AtomPub, I suggest that you have
a look at the Atomojo project from Alex Milowski which is based on Restlet:
http://code.google.com/p/atomojo/ 
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : David Fogel [mailto:carrotsa...@gmail.com] 
Envoyé : vendredi 10 avril 2009 21:36
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode

That's a funny coincidence- I was just looking at Restlet's Atom extension
and wondering why there weren't any Resource implementations there.  Unless
I'm missing something, it looks like the ext.atom package is a set of java
objects modeling the data in APP xml, that know how to serialize/deserialize
themselves to/from xml...

-Dave

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=16348
79

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1731611

Re: ServerResource conditional mode

[David Fogel]

That's a funny coincidence- I was just looking at Restlet's Atom
extension and wondering why there weren't any Resource implementations
there.  Unless I'm missing something, it looks like the ext.atom
package is a set of java objects modeling the data in APP xml, that
know how to serialize/deserialize themselves to/from xml...

-Dave

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1634879

Re: ServerResource conditional mode

[David Bordoley]

Have you considered that having a generic server resource might be a
bit to simplistic or not granular enough? I guess from my point of
view the resource class is really the implementation of the gritty
protocol details of your application. I'm wondering if at least in
addition to ServerResource, if resources such as
AtomPubCollectionResource and AtomPubEntryResource would be useful to
implementors who want to use standard RESTful protocols without
needing to dig into the details.

thanks,

Dave

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1634241

Re: ServerResource conditional mode

[Tal Liron]

Supple,
ingenious, creative, compassionate, endlessly-open minds think alike!

Jerome Louvel wrote:


  
  
  
  I had the same thought and updated SVN trunk a
couple of minutes ago with the exact same code ;)
  
  
   
  
  
  Best regards,
Jerome Louvel
--
  Restlet ~ Founder and Lead developer ~ http://www.restlet.org
  Noelios Technologies ~ Co-founder ~ http://www.noelios.com
  
  
   
  
  De : Tal Liron
[mailto:tal.li...@threecrickets.com] 
  Envoyé : vendredi 10 avril 2009 20:09
  À : discuss@restlet.tigris.org
  Objet : Re: ServerResource conditional mode
  
  
  Pretty good... except what if the user throws a
ResourceException with a specific status code? I suggest something like
this instead:
  
  catch(InvocationTargetException e) {
    Throwable te = e.getTargetException();
    if (te instanceof ResourceException) {
       throw (ResourceException) te;
    } else {
       throw new ResourceException(te);
    }
}
  
  
Jerome Louvel wrote:
  

Tal,
 
Thanks for this issue report.
 
I've changed the ServerResource behavior to
rethrow checked exceptions of annotated method as ResourceExceptions.
This result in a 500 (Internal server error) status being set by the
ServerResource#handle() method.


 


Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


 


 De : Tal
Liron [mailto:tal.li...@threecrickets.com]

Envoyé : jeudi 9 avril 2009 00:06
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode


Jerome,
regarding exceptions caught --


You've
implemented this only for when users override methods in non-annotated
mode. In annotated mode, exceptions are still not allowed. This leads
to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions
across the board would result in better user code.


If
you decide that you do want to handle exceptions for annotated
handlers, see doHandle(AnnotationInfo): you would need to get the
reflected exception via InvocationTargetException.getTargetException().


Whatever
you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.



-Tal


Jerome Louvel wrote:


  
  2) Exceptions caught
   
  Currently (SVN trunk at least), the
ResourceExceptions are caught and the response status is updated
accordingly. This is done in the ServerResource#handle() method. Other
exceptions will be caught upper in the processing chain, by the
StatusService for example. 
   
  We do have some plans to extend the
ConverterService in order to automatically convert common exceptions
into matching statuses, but I'm not clear yet whether this is such a
good idea (JAX-RS has this).

  

RE: ServerResource conditional mode

[Jerome Louvel]

I had the same thought and updated SVN trunk a couple of minutes ago with
the exact same code ;)
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  <http://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  <http://www.noelios.com/>
http://www.noelios.com
 
  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : vendredi 10 avril 2009 20:09
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode


Pretty good... except what if the user throws a ResourceException with a
specific status code? I suggest something like this instead:

catch(InvocationTargetException e) {
Throwable te = e.getTargetException();
if (te instanceof ResourceException) {
   throw (ResourceException) te;
} else {
   throw new ResourceException(te);
}
}


Jerome Louvel wrote: 

Tal,
 
Thanks for this issue report.
 
I've changed the ServerResource behavior to rethrow checked exceptions of
annotated method as ResourceExceptions. This result in a 500 (Internal
server error) status being set by the ServerResource#handle() method.

 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  <http://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  <http://www.noelios.com/>
http://www.noelios.com
 

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : jeudi 9 avril 2009 00:06
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode



Jerome, regarding exceptions caught --




You've implemented this only for when users override methods in
non-annotated mode. In annotated mode, exceptions are still not allowed.
This leads to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions across
the board would result in better user code.




If you decide that you do want to handle exceptions for annotated handlers,
see doHandle(AnnotationInfo): you would need to get the reflected exception
via InvocationTargetException.getTargetException().




Whatever you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.





-Tal



Jerome Louvel wrote:


2) Exceptions caught
 
Currently (SVN trunk at least), the ResourceExceptions are caught and the
response status is updated accordingly. This is done in the
ServerResource#handle() method. Other exceptions will be caught upper in the
processing chain, by the StatusService for example. 
 
We do have some plans to extend the ConverterService in order to
automatically convert common exceptions into matching statuses, but I'm not
clear yet whether this is such a good idea (JAX-RS has this).

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1634003

Re: ServerResource conditional mode

[Tal Liron]

Pretty good... except what if the user throws a
ResourceException with a specific status code? I suggest something like
this instead:

catch(InvocationTargetException e) {
    Throwable te = e.getTargetException();
    if (te instanceof ResourceException) {
       throw (ResourceException) te;
    } else {
       throw new ResourceException(te);
    }
}


Jerome Louvel wrote:

  
  
  Tal,
   
  Thanks for this issue report.
   
  I've changed the ServerResource behavior to
rethrow checked exceptions of annotated method as ResourceExceptions.
This result in a 500 (Internal server error) status being set by the
ServerResource#handle() method.
  
  
   
  
  
  Best regards,
Jerome Louvel
--
  Restlet ~ Founder and Lead developer ~ http://www.restlet.org
  Noelios Technologies ~ Co-founder ~ http://www.noelios.com
  
  
   
  
  
  De : Tal Liron
[mailto:tal.li...@threecrickets.com] 
  Envoyé : jeudi 9 avril 2009 00:06
  À : discuss@restlet.tigris.org
  Objet : Re: ServerResource conditional mode
  
  
  Jerome,
regarding exceptions caught --
  
  
  You've
implemented this only for when users override methods in non-annotated
mode. In annotated mode, exceptions are still not allowed. This leads
to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions
across the board would result in better user code.
  
  
  If
you decide that you do want to handle exceptions for annotated
handlers, see doHandle(AnnotationInfo): you would need to get the
reflected exception via InvocationTargetException.getTargetException().
  
  
  Whatever
you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.
  
  
  
  -Tal
  
  
Jerome Louvel wrote:
  
  

2) Exceptions caught
 
Currently (SVN trunk at least), the
ResourceExceptions are caught and the response status is updated
accordingly. This is done in the ServerResource#handle() method. Other
exceptions will be caught upper in the processing chain, by the
StatusService for example. 
 
We do have some plans to extend the
ConverterService in order to automatically convert common exceptions
into matching statuses, but I'm not clear yet whether this is such a
good idea (JAX-RS has this).
  

RE: ServerResource conditional mode

[Jerome Louvel]

Tal,
 
Thanks for this issue report.
 
I've changed the ServerResource behavior to rethrow checked exceptions of
annotated method as ResourceExceptions. This result in a 500 (Internal
server error) status being set by the ServerResource#handle() method.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  <http://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  <http://www.noelios.com/>
http://www.noelios.com
 

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : jeudi 9 avril 2009 00:06
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode



Jerome, regarding exceptions caught --




You've implemented this only for when users override methods in
non-annotated mode. In annotated mode, exceptions are still not allowed.
This leads to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions across
the board would result in better user code.




If you decide that you do want to handle exceptions for annotated handlers,
see doHandle(AnnotationInfo): you would need to get the reflected exception
via InvocationTargetException.getTargetException().




Whatever you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.





-Tal



Jerome Louvel wrote:


2) Exceptions caught
 
Currently (SVN trunk at least), the ResourceExceptions are caught and the
response status is updated accordingly. This is done in the
ServerResource#handle() method. Other exceptions will be caught upper in the
processing chain, by the StatusService for example. 
 
We do have some plans to extend the ConverterService in order to
automatically convert common exceptions into matching statuses, but I'm not
clear yet whether this is such a good idea (JAX-RS has this).

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1633744

RE: ServerResource conditional mode

[Jerome Louvel]

Tal,
 
My understanding is that conditional POST/PUT require the presence of an
existing resource/state to check the conditions on.
 
The latest behavior in SVN trunk should NOT trigger a GET if you do a POST
or a PUT *without* any condition specified. If this still doesn't work then
it is a bug.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  <http://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  <http://www.noelios.com/>
http://www.noelios.com

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : mercredi 8 avril 2009 23:55
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode



Jerome,




I understand If-Match, but I'm still confused by ServerResource's support of
it in conditional mode. Logically, POST and PUT should work even if there is
no entity, right?





Right now, my GET returns an error status because there is no entity, but
then I can't get POST/PUT to work while in conditional mode because of that.
No entity, no possibility of checking conditions... which doesn't make sense
to me.





It seems to me that if GET doesn't return a value, then POST and PUT should
continue as normal in conditional mode. Could the problem be that I'm
setting an error status? But, then, I do need to set an error status for
true failures of GET...




I'm still confused!





-Tal



Jerome Louvel wrote:


Hi Tal,
 
The conditional mode is here to support HTTP conditional methods as
explained for the "If-Match" header:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24
 
The idea is that before executing some methods (PUT, POST, etc.), it is
possible to check whether the resource state has changed (tag or date
comparison). This check has to be done on the entity that would have been
returned by an equivalent GET. So we have to simulate a GET in order to
check conditions, whatever is the actual method handled.
 
Now, there is no reason to simulate the GET if the client hasn't expressed
any condition. I have fixed ServerResource#doConditionalHandle() so it will
work fine in your cases. 
 
Just note that if your client do express some conditions, the ServerResource
will expect your subclasses to provide support for GET or else it will
result in an error. I think this is reasonable and you can always turn off
conditional processing if you really don't want to provide GET
implementation.
 
Hope this clarifies.

 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  <http://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  <http://www.noelios.com/>
http://www.noelios.com
 

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : jeudi 2 avril 2009 23:20
À : discuss@restlet.tigris.org
Objet : ServerResource conditional mode



Hi,




Does someone have a grasp on what conditional mode is for and how it used?




It's enabled by default, but I had to disable it for one of my resources to
work with PUT and POST. The issue is that it always calls doGetInfo first,
which for my particular resource will fail, and so calls to PUT and POST
also fail.


Also, it seems to me that calling doGetInfo for every request, even for
methods that are not GET, is wasteful. In short, I simply don't understand
why this check happens, and subsequently what exactly conditional mode is
doing. :)

-Tal

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1633548

Re: ServerResource conditional mode

[Tal Liron]

Jerome,
regarding exceptions caught --


You've
implemented this only for when users override methods in non-annotated
mode. In annotated mode, exceptions are still not allowed. This leads
to different ways of doing things if you're in annotated or
non-annotated mode. Personally, I think that disallowing exceptions
across the board would result in better user code.


If
you decide that you do want to handle exceptions for annotated
handlers, see doHandle(AnnotationInfo): you would need to get the
reflected exception via InvocationTargetException.getTargetException().


Whatever
you decide, I recommend that the same allowances be made for both
annotated and non-annotated mode.




-Tal





Jerome Louvel wrote:


  
  
  2) Exceptions caught
   
  Currently (SVN trunk at least), the
ResourceExceptions are caught and the response status is updated
accordingly. This is done in the ServerResource#handle() method. Other
exceptions will be caught upper in the processing chain, by the
StatusService for example. 
   
  We do have some plans to extend the
ConverterService in order to automatically convert common exceptions
into matching statuses, but I'm not clear yet whether this is such a
good idea (JAX-RS has this).

Re: ServerResource conditional mode

[Tal Liron]

Jerome,



I
understand If-Match, but I'm still
confused by ServerResource's support of it in conditional mode.
Logically, POST and PUT should work even if there is no entity, right?



Right
now, my GET returns an error status because there is no entity, but
then I can't get POST/PUT to work while in conditional mode because of
that. No entity, no possibility of checking conditions... which doesn't
make sense to me.



It
seems to me that if GET doesn't return a value, then POST and PUT
should continue as normal in conditional mode. Could the problem be
that I'm setting an error status? But, then, I do need to set an error
status for true failures of GET...


I'm
still confused!







-Tal



Jerome Louvel wrote:


  
  
  Hi Tal,
   
  The conditional mode is here to support HTTP
conditional methods as explained for the "If-Match" header:
  http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24
   
  The idea is that before executing some methods
(PUT, POST, etc.), it is possible to check whether the resource state
has changed (tag or date comparison). This check has to be done on the
entity that would have been returned by an equivalent GET. So we have
to simulate a GET in order to check conditions, whatever is the actual
method handled.
   
  Now, there is no reason to simulate the GET if
the client hasn't expressed any condition. I have fixed
ServerResource#doConditionalHandle() so it will work fine in your
cases. 
   
  Just note that if your client do express some
conditions, the ServerResource will expect your subclasses to provide
support for GET or else it will result in an error. I think this is
reasonable and you can always turn off conditional processing if you
really don't want to provide GET implementation.
   
  Hope this clarifies.
  
  
   
  
  
  Best regards,
Jerome Louvel
--
  Restlet ~ Founder and Lead developer ~ http://www.restlet.org
  Noelios Technologies ~ Co-founder ~ http://www.noelios.com
  
  
   
  
  
  De : Tal Liron
[mailto:tal.li...@threecrickets.com] 
  Envoyé : jeudi 2 avril 2009 23:20
  À : discuss@restlet.tigris.org
  Objet : ServerResource conditional mode
  
  
  Hi,
  
  
  Does
someone have a grasp on what conditional mode is for and how it used?
  
  
  It's
enabled by default, but I had to disable it for one of my resources to
work with PUT and POST. The issue is that it always calls doGetInfo
first, which for my particular resource will fail, and so calls to PUT
and POST also fail.
  
  Also, it seems to me that calling doGetInfo
for every request, even for methods that are not GET, is wasteful. In
short, I simply don't understand why this check happens, and
subsequently what exactly conditional mode is doing. :)
  -Tal
  

RE: ServerResource conditional mode

[Jerome Louvel]

Hi all,
 
Let me try to reply to the rest on this thread in one mail.
 
1) Multiple POST/PUT methods for different types of request entity
 
It will be possible to specify the media type of the entity passed to POST
and PUT methods in the annotation value, in addition to specifying the
optional media type of the returned entity.
 
Again, you can find a bit more details in the specifications page (see
"Annotations parameter" paragraph):
http://wiki.restlet.org/developers/172-restlet/226-restlet.html
 
There are examples given:
@Get("xml") : Returns a representation in the "text/xml" media type

String toString();



@Put("xml") : Stores representations in the "text/xml" media type after
conversion to a DOM document

void store(Document doc)



@Put("text:xml") : Stores representations in the "text/xml" media type after
conversion to a DOM document and returns a plain text response

String store(Document doc)
This isn't implemented yet, this is the next step for 1.2 M3.
 
2) Exceptions caught
 
Currently (SVN trunk at least), the ResourceExceptions are caught and the
response status is updated accordingly. This is done in the
ServerResource#handle() method. Other exceptions will be caught upper in the
processing chain, by the StatusService for example. 
 
We do have some plans to extend the ConverterService in order to
automatically convert common exceptions into matching statuses, but I'm not
clear yet whether this is such a good idea (JAX-RS has this).
 
3) Variants declaration
 
Currently, there is a modifiable map (Maphttp://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  <http://www.noelios.com/>
http://www.noelios.com

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : vendredi 3 avril 2009 09:46
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode



You don't need to put a media type if you're using void (although, you could
potentially have more than one @Post handler, for several media types, to be
used depending on the expectation of a media type from the client...).




But, you do need to disable conditional mode:


@Post

public void handlePost(Representation rep) { ... }

@Override
protected void init()
{
setConditional(false);
}





Why? I'm still a bit in the dark about this. My current instinct tells me
that there's a bug in how the preferred variant is calculated for
conditional mode, in that it doesn't gather variants for the particular
method. Thus, I suspect (I haven't tested this) that if you had a @Get with
a particular media type (say, @Get("txt")) then there would be a preferred
variant and your @Post would be called, even in conditional mode.




Please take that last paragraph with a truckload of salt. :)




-Tal



David Fogel wrote:


Hi Tal-



I will definitely take a look at your script extension, thanks for the

suggestion!



I think I understand the general deal with the mediatype annotation

argument.  But like I said, I was trying to define a Post method that

doesn't return content (and which therefore wouldn't make sense to

declare a mediatype for.  So what's the right annotation argument for

this method?



@Post("[what goes here?]")

public void handlePost(Representation rep) { ... }



what I found was that I had to put a return type or a mediatype, or

else ServerResource refuses to call the method, due to the lack of a

"preferredVariant".



-Dave



--

http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447
<http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1529
543> &dsMessageId=1529543

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1593276

RE: ServerResource conditional mode

[Jerome Louvel]

Hi Dave,

As I just explained in reply to Tal, your initial issue with POST is now
addressed in SVN trunk. Hope this makes sense now what conditional
processing is for.

Regarding the support for annotations directly in ServerResource, I
initially thought about separating them, but felt that it would be nice to
be able to mix both approaches in some cases. In is also easier for somebody
to port his existing pre-1.2 resources to the new API and progressively
leverage annotations. 

This isn't fixed in stone though and we have time for refactoring before 1.2
RC. Regarding the lack of documentation and explanation, this is mainly due
to the fact that this is still work in progress and the design isn't final
yet. The goal of Restlet 1.2 M2 was to get some early feed-back from the
community to adjust what needs to be.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

 

-Message d'origine-
De : David Fogel [mailto:carrotsa...@gmail.com] 
Envoyé : vendredi 3 avril 2009 07:27
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode

Hi Tal-

I've been struggling with that very question, as I, too had trouble with
POSTing to my new ServerResource subclass.

I also noticed that getPreferredVariant(Method.GET) is called during
processing of the POST request, and I couldn't figure out why.

At first I thought that was the cause of my problems, but it turned out that
my problem was in the 2nd time through getPreferredVariant(), in
doNegotiatedHandle(), this time called with (the correct) Method.POST.  This
method was always returning a 406 status - CLIENT_ERROR_NOT_ACCEPTABLE.

my post method looked something like this:

@Post
public void postSomeData(Representation entity) throws ResourceException {

}

the getPreferredVariant code checks the Java return-type of the annotated
method, and in this case having a void return type meant that
getPreferredVariant returns null, which causes the doNegotiatedHandle to
return 406.

This doesn't seem like quite the right thing, since it's not clear to me
exactly what kind of content negotation can really usefully go on in the
(fairly common) case of a POST method which processes Form data and then
returns 204- success-no-content.  It's also not clear to me whether I should
have given the @Post a mediatype value- should this be the incoming
representation type of form-url-encoded, or something else?  not sure at
all.

I'd love to see some greater amount of docs or general explanation of what
the thinking is here, or else I fear this will cause significant confusion
for people...  I found it particularly confusing how ServerResource combines
support for both annotated and non-annotated subclasses.  Maybe support for
these two approaches should be broken out into two classes?

-Dave Fogel

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=15288
27

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1593013

RE: ServerResource conditional mode

[Jerome Louvel]

Hi Tal,
 
The conditional mode is here to support HTTP conditional methods as
explained for the "If-Match" header:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24
 
The idea is that before executing some methods (PUT, POST, etc.), it is
possible to check whether the resource state has changed (tag or date
comparison). This check has to be done on the entity that would have been
returned by an equivalent GET. So we have to simulate a GET in order to
check conditions, whatever is the actual method handled.
 
Now, there is no reason to simulate the GET if the client hasn't expressed
any condition. I have fixed ServerResource#doConditionalHandle() so it will
work fine in your cases. 
 
Just note that if your client do express some conditions, the ServerResource
will expect your subclasses to provide support for GET or else it will
result in an error. I think this is reasonable and you can always turn off
conditional processing if you really don't want to provide GET
implementation.
 
Hope this clarifies.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com
 

  _  

De : Tal Liron [mailto:tal.li...@threecrickets.com] 
Envoyé : jeudi 2 avril 2009 23:20
À : discuss@restlet.tigris.org
Objet : ServerResource conditional mode



Hi,




Does someone have a grasp on what conditional mode is for and how it used?




It's enabled by default, but I had to disable it for one of my resources to
work with PUT and POST. The issue is that it always calls doGetInfo first,
which for my particular resource will fail, and so calls to PUT and POST
also fail.


Also, it seems to me that calling doGetInfo for every request, even for
methods that are not GET, is wasteful. In short, I simply don't understand
why this check happens, and subsequently what exactly conditional mode is
doing. :)

-Tal

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1592827

Re: ServerResource conditional mode

[Tal Liron]

You
don't need to put a media type if you're using void (although, you
could potentially have more than one @Post handler, for several media
types, to be used depending on the expectation of a media type
from the client...).


But,
you do need to disable conditional mode:

@Post
public void handlePost(Representation rep) { ... }

@Override
protected void init()
{
    setConditional(false);
}




Why?
I'm still a bit in the dark about this. My current instinct tells me
that there's a bug in how the preferred variant is calculated for
conditional mode, in that it doesn't gather variants for the particular
method. Thus, I suspect (I haven't tested this) that if you had a @Get
with a particular media type (say, @Get("txt")) then there would be a
preferred variant and your @Post would be called, even in conditional
mode.


Please
take that last paragraph with a truckload of salt. :)


-Tal





David Fogel wrote:


  Hi Tal-

I will definitely take a look at your script extension, thanks for the
suggestion!

I think I understand the general deal with the mediatype annotation
argument.  But like I said, I was trying to define a Post method that
doesn't return content (and which therefore wouldn't make sense to
declare a mediatype for.  So what's the right annotation argument for
this method?

@Post("[what goes here?]")
public void handlePost(Representation rep) { ... }

what I found was that I had to put a return type or a mediatype, or
else ServerResource refuses to call the method, due to the lack of a
"preferredVariant".

-Dave

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1529543
  

Re: ServerResource conditional mode

[David Fogel]

Hi Tal-

I will definitely take a look at your script extension, thanks for the
suggestion!

I think I understand the general deal with the mediatype annotation
argument.  But like I said, I was trying to define a Post method that
doesn't return content (and which therefore wouldn't make sense to
declare a mediatype for.  So what's the right annotation argument for
this method?

@Post("[what goes here?]")
public void handlePost(Representation rep) { ... }

what I found was that I had to put a return type or a mediatype, or
else ServerResource refuses to call the method, due to the lack of a
"preferredVariant".

-Dave

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1529543

Re: ServerResource conditional mode

[Tal Liron]

David,



The
MediaType extension as an argument for the @Get, @Post, @Put and
@Delete annotation is always for the returned representation, not
for the entity sent from the client. Restlet does not do anything with
what the client sends you -- it's up to you to process the entity,
support various MediaTypes, languages, encodings, etc.


Note
that ServerResource offers you quite a bit of flexibility as to the
return type of the Java method. You can set it to void if you never
want to return a value (useful for @Delete), to anything that can be
cast into Representation, or to String, in which case you get it
converted internally to a StringRepresentation.


By
the way, in annotated mode, you should not throw any exceptions
from your handling methods! ServerResource simply collapses if it gets
an exception (it internally uses reflection to call your handler, and
does not expect wrapped exceptions). The correct way to set an error
seems to be to call ServerResource.setStatus() (which is a shortcut to
getResponse().setStatus()), and to return null. Personally, I think
this is a good idea, as it puts higher demands on quality for resource
writers. Too often people just add a "throws" clause to their methods
and think all is well. Without this, people will have to give more
thought into how they handle errors and what status to send to the
client.





Example:



@Post("xml")
DomRepresentation
acceptReturnXml(Representation
entity) { accept(entity); return .. }



@Post("json")
JsonRepresentation
acceptReturnJson(Representation
entity) { accept(entity); return ..
}


private void accept(Representation
entity) { ... }




The
slight annoyance here is that you can't have both methods called
"accept()", because Java won't allow it. But, you can have both methods
call a utility method, as I show here. I agree that this is very
confusing and it took me a while to figure this out -- I hope that
Jerome can add something like this to the tutorial, which currently is
too @Get-focused. :)



I've
been poking around and have some ideas about the difference between
conditional and negotiated mode, and why they might be useful, but I'm
still confused by a few things. Let's wait for Jerome to better explain
this (and hopefully provide fuller Java API documentation...) This is
just M2! I'm sure the final release of Restlet 1.2 will be crystal
clear.



If
you'd like to see examples for non-annotated use of ServerResource, see
svn for the script extension, which I've successfully (well, it works!)
converted to ServerResource. There are quite a few tricks involved,
which again demand much more documentation. For example, you need to
override different methods depending on whether you are in negotiated
or non-negotiated mode, and the map of acceptable variants supports
either Variants, MediaType instances, or List instances containing the
previous two, and you can set these per Method, or have them set to
Method.ALL... important stuff that's nowhere documented.




-Tal



David Fogel wrote:


  Hi Tal-

I've been struggling with that very question, as I, too had trouble
with POSTing to my new ServerResource subclass.

I also noticed that getPreferredVariant(Method.GET) is called during
processing of the POST request, and I couldn't figure out why.

At first I thought that was the cause of my problems, but it turned
out that my problem was in the 2nd time through getPreferredVariant(),
in doNegotiatedHandle(), this time called with (the correct)
Method.POST.  This method was always returning a 406 status -
CLIENT_ERROR_NOT_ACCEPTABLE.

my post method looked something like this:

@Post
public void postSomeData(Representation entity) throws ResourceException {

}

the getPreferredVariant code checks the Java return-type of the
annotated method, and in this case having a void return type meant
that getPreferredVariant returns null, which causes the
doNegotiatedHandle to return 406.

This doesn't seem like quite the right thing, since it's not clear to
me exactly what kind of content negotation can really usefully go on
in the (fairly common) case of a POST method which processes Form data
and then returns 204- success-no-content.  It's also not clear to me
whether I should have given the @Post a mediatype value- should this
be the incoming representation type of form-url-encoded, or something
else?  not sure at all.

I'd love to see some greater amount of docs or general explanation of
what the thinking is here, or else I fear this will cause significant
confusion for people...  I found it particularly confusing how
ServerResource combines support for both annotated and non-annotated
subclasses.  Maybe support for these two approaches should be broken
out into two classes?

-Dave Fogel

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1528827
  

Re: ServerResource conditional mode

[David Fogel]

Hi Tal-

I've been struggling with that very question, as I, too had trouble
with POSTing to my new ServerResource subclass.

I also noticed that getPreferredVariant(Method.GET) is called during
processing of the POST request, and I couldn't figure out why.

At first I thought that was the cause of my problems, but it turned
out that my problem was in the 2nd time through getPreferredVariant(),
in doNegotiatedHandle(), this time called with (the correct)
Method.POST.  This method was always returning a 406 status -
CLIENT_ERROR_NOT_ACCEPTABLE.

my post method looked something like this:

@Post
public void postSomeData(Representation entity) throws ResourceException {

}

the getPreferredVariant code checks the Java return-type of the
annotated method, and in this case having a void return type meant
that getPreferredVariant returns null, which causes the
doNegotiatedHandle to return 406.

This doesn't seem like quite the right thing, since it's not clear to
me exactly what kind of content negotation can really usefully go on
in the (fairly common) case of a POST method which processes Form data
and then returns 204- success-no-content.  It's also not clear to me
whether I should have given the @Post a mediatype value- should this
be the incoming representation type of form-url-encoded, or something
else?  not sure at all.

I'd love to see some greater amount of docs or general explanation of
what the thinking is here, or else I fear this will cause significant
confusion for people...  I found it particularly confusing how
ServerResource combines support for both annotated and non-annotated
subclasses.  Maybe support for these two approaches should be broken
out into two classes?

-Dave Fogel

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1528827