Hi there,
We had several discussions on this topic. Although PUT with an empty
entity isn't a RESTful design practice, Restlet shouldn't enforce it as
the HTTP spec is unclear about it.
Also, we didn't enforce it correctly as the test wasn't working with
chunked encoding or when the size wasn'
Awesome. I didn't know this effort existed. I did not see that they have
already cleared up this point in the drafts, although they did shed light on
the Status code issue in another thread.
I'll join the list ... this is stuff we should stay abreast of.
- R
Someone might consider putting this question to the people doing the
2616bis update to HTTP. See
http://www.ietf.org/html.charters/httpbis-charter.html - there is a
mailing list.
As I understand it, part of their charter is to clarify some of the
murkier pieces of the spec; this sounds like it mi
Hi Rob,
On Jan 14, 2008, at 9:50 AM, Rob Heittman wrote:
2.) Send a default entity body so the request goes through.
I think this is the way to go, honestly, even if it lacks the purity
Rhett is looking for.
My interpretation of the spec is that an entity is required for a PUT
I always
>
> 1.) Instead of sending a PUT to
> /resource1/{r1_identifier}/resource2/{r2_identifier}, you could try
> sending a PUT to /resource1/{r1_identifier}/resource2/ with
> {r2_identifier} as the entity body?
It's not reversible for a many to many relationship unless
/resource1/{r1_identifier}/resou
I see.
I can think of two options:
1.) Instead of sending a PUT to
/resource1/{r1_identifier}/resource2/{r2_identifier}, you could try
sending a PUT to /resource1/{r1_identifier}/resource2/ with
{r2_identifier} as the entity body?
2.) Send a default entity body so the request goes through.
My i
Hi Kevin,
On Jan 14, 2008, at 8:38 AM, Kevin Conaway wrote:
Are you overriding allowPut() in your Resource class? You need to
do as such:
@Override
public boolean allowPut() {
return true;
}
I should have been more clear -- the scheme I described works fine if
there's an entity provide
Hi Rob,
On Jan 14, 2008, at 12:13 AM, Rob Heittman wrote:
I can't fault your design given your constraints. I think the
general concept: identifying links with hierarchical URIs descending
from the URI of each linked object, is at least a common idiom if
not an established pattern. I have
Are you overriding allowPut() in your Resource class? You need to do as such:
@Override
public boolean allowPut() {
return true;
}
On Jan 13, 2008 10:20 PM, Rhett Sutphin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm designing & implementing my first REST-style API. It's for an
> existing applicat
I can't fault your design given your constraints. I think the general
concept: identifying links with hierarchical URIs descending from the URI of
each linked object, is at least a common idiom if not an established
pattern. I have both seen and used this style a number of times.
I have also see
Hi,
I'm designing & implementing my first REST-style API. It's for an
existing application. I'm using Restlet 1.1-M1 and have found it very
cleanly designed and easy to use.
I've run into a problem where I can't seem to implement one of the
resources in the way that makes most sense to
11 matches
Mail list logo
