Hi Ben,
[...]
What main benefits are there for me in upgrading to the (future 1.1)
version?
If you are not planning to go into production soon, you would be able to
leverage many enhancements and to help us with tests and maybe coding. See
latest changes log:
Hi Ben,
You can also try with different Restlet HTTP client connector. Otherwise, a
reproducible test case would help us to pinpoint the issue. Feel free to
open a defect report in the tracker.
Best regards,
Jerome
2007/12/6, Stephan Koops [EMAIL PROTECTED]:
Hello Ben,
do you checked, if
In the case you give, I would use a redirect, with Response.redirectOther as
described in http://permalink.gmane.org/gmane.comp.java.restlet/2971 -- for
exactly the reason Stephan describes. This is established practice as
codified in the HTTP RFCs, and ensures that any random well-behaved user
The sense the redirection after POST is to clean the browser cache from
POST requests to avoid a resend this call again when running threw the
history with the back and forward buttons. If you implement for a
browser, than you should send a redirect. If you implementing only as
web service,
The POST is creating a new resource in the persistence layer, then
returning, as text, the URL to that new resource. It just strikes me
that returning the textual representation of the URL is a GET operation
and should be treated as such, no? Redirecting and writing to the
Response both
My apologies if this has been discussed too many times already. I'm
using JDK 1.5.x with Restlet 1.0.6.
I think I've come to the conclusion that to return something from a
POST, the best way is to forward to a GET on another resource, sound
right? I could write to the Response directly, but
I think, before I made any sound observations, I'd want to know more about
your use case and what functional effects are exposed by this particular
POST.
In general, there's nothing illicit about POST returning either a meaningful
representation, or a redirect. Either of these are the two most
7 matches
Mail list logo
