: John D. Mitchell [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 1 août 2007 18:09
À : discuss@restlet.tigris.org
Objet : Re: 404 from getRepresentation/handleGet?
On 8/1/07, John D. Mitchell [EMAIL PROTECTED] wrote:
On 7/26/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote:
[...]
Actually, I'd
On 8/3/07, Jerome Louvel [EMAIL PROTECTED] wrote:
[...]
You are right and I've updated the behavior in SVN trunk. Now, if
Resource.getRepresentation(Variant) returns 'null', the Resource.handleGet()
method returns a NOT_FOUND (404) status.
Note that we already generate a 406 if no variant is
On 27 Jul 2007, at 18:32, Adam Taft wrote:
Maybe you have a good reason to create all your representations in
the constructor of the Resource?
To avoid the boring
if (myvariant1.includes(v) {
..
} { else if (myvariant2.includes(v) {
..
} ...
dance you can put the
On 7/26/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote:
[...]
4 - Do The Work Later
Do very little in the constructor; toss in a variant in the hopes the resource
exists.
I.e., add all of the standard types that we support across the
entire application (i.e., in an abstract base class).
If
On 8/1/07, John D. Mitchell [EMAIL PROTECTED] wrote:
On 7/26/07, Geoffrey Wiseman [EMAIL PROTECTED] wrote:
[...]
Actually, I'd be happy with this if Resource.handleGet() treated a null from
getRepresentation as a 404, but that might not work for all cases?
Yes, I've been bitten by
Stian Soiland wrote:
See http://restlet.tigris.org/issues/show_bug.cgi?id=303 for the
enhancement request.
Thanks for posting that RFE, I hadn't seen it...
In my code, I need each Resource to have a different set of converters,
so the ConverterService solution wouldn't really work for me. I
On 7/26/07, Adam Taft [EMAIL PROTECTED] wrote:
You're asking what's the best practice to use when coding your Resource.
Exactly!
This approach allows the library to do the automatic content negotiation
and call getRepresentation(Variant v) with the appropriate Variant. If
you short circuit
the deletion.
Best regards,
Jerome
-Message d'origine-
De : Adam Taft [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 27 juillet 2007 19:33
À : discuss@restlet.tigris.org
Objet : Re: 404 from getRepresentation/handleGet?
Geoffrey Wiseman wrote:
This approach allows the library
Geoffrey Wiseman wrote:
This approach allows the library to do the automatic content negotiation
and call getRepresentation(Variant v) with the appropriate Variant. If
you short circuit this and add in your Representation during
construction, basically you miss out on the ability to switch
Adam Taft adam at adamtaft.com writes:
a) GET should NEVER! change the state of an object. I'm confused as to
how/why you are mixing a DELETE operation and a GET operation together.
I'm probably mis-reading.
Yes, I must not have been clear. My GETs aren't changing the state of an
Hi all,
This is an interesting thread and I don't have any strong opinion on it
yet. Maybe it would be useful to relaunch this thread in the
REST-Discuss list on Yahoo. You could get the opinion of the larger REST
community and potentially of Roy T. Fielding too.
Best regards,
Jerome
Hello Geoffrey,
If you've got a resource that handles GET and DELETE and has one or more
representations that require a certain amount of effort to instantiate, but
might 404 based on information out of the database, what's the usual pattern to
handle this?
On the one end of the spectrum, I
-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 4:41 PM
To: discuss@restlet.tigris.org
Subject: Re: 404 from getRepresentation/handleGet?
[. . .]
I hope this will help you,
Thierry Boileau
p.s.: DELETE method does not return 404
Erik Hetzner wrote:
A counterexample.
Right, but see, your resource changed from the first PUT request.
Therefore the Precondition Failed status code is appropriate. Again, if
a resource doesn't change, neither can its status code. The two are
linked together.
If your resource hadn't
Hi Adam,
At Wed, 18 Jul 2007 11:11:54 -0600,
Adam Taft [EMAIL PROTECTED] wrote:
Right, but see, your resource changed from the first PUT request.
Therefore the Precondition Failed status code is appropriate. Again,
if a resource doesn't change, neither can its status code. The two
are
Erik Hetzner wrote:
The point is, the state AFTER each request is processed is the same,
but the status code is different. You have argued, w.r.t. DELETE, that
as long as we have the same resource state after the request is
processed, we must have the same response, whatever the previous state
Basically, I concur with Adam so I'm just going to respond to a couple
of nits...
On 7/17/07, Erik Hetzner [EMAIL PROTECTED] wrote:
At Tue, 17 Jul 2007 17:57:16 -0700,
John D. Mitchell [EMAIL PROTECTED] wrote:
I read this as 'side effect', like a side effect in functional
programming. I
On 7/18/07, Erik Hetzner [EMAIL PROTECTED] wrote:
[...]
PUT is also must be idempotent precisely because multiple puts of
the same stuff to the same place gives the same results.
Again, to be clear, and I believe this is the crux of our
disagreement:
9.1.2.
| Methods can also have the
At Wed, 18 Jul 2007 18:33:29 -0700,
John D. Mitchell [EMAIL PROTECTED] wrote:
(A) Well, to refer to authority... :-)
http://dictionary.reference.com/search?r=2q=idempotent
http://en.wikipedia.org/wiki/Idempotence_(computer_science)
I agree that the definition of idempotence there conflicts
If you've got a resource that handles GET and DELETE and has one or more
representations that require a certain amount of effort to instantiate, but
might 404 based on information out of the database, what's the usual pattern to
handle this?
On the one end of the spectrum, I could create both
I'm having a hard time following. But, being a baby RESTafarian, I
noted a couple of design issues which I think might help you. Maybe you
already know these principles though:
a) GET should NEVER! change the state of an object. I'm confused as to
how/why you are mixing a DELETE
At Tue, 17 Jul 2007 17:57:16 -0700,
John D. Mitchell [EMAIL PROTECTED] wrote:
I read this as 'side effect', like a side effect in functional
programming. I tend to agree that it would be good if you got then
same response, but the constraint is that you simply get the same side
effects,
At Tue, 17 Jul 2007 20:56:48 -0600,
Adam Taft [EMAIL PROTECTED] wrote:
Erik Hetzner wrote:
[…] ‘idempotent’ means repeating the operation ends up with the
resource in the same state (it doesn't mean all the responses are
always identical).
What we're saying is that _because_ the resource
23 matches
Mail list logo
