Rob,
Do you have any metric that points to which browsers do or do not
support a 201 Created status / Location header combination? I'd be
interested in knowing as I'm having a hard time finding a definitive
answer to this question.
Regardless of client method, my experience has been this
Well, like I said, I don't do broad testing or anything, so I honestly
didn't know. It's just more my gut feeling that this works acceptably.
I agree, it definitely didn't work back in the good old days! ;)
Adam
p.s. thanks for the continued play on words. my wife: what are you
Sean Landis wrote:
We'd like to have a single resource and URI (GET http://host:port/service/foo)
and return HTML if the client is a browser, and return something more
machine friendly for a web service client. We use a lot of XML with JAXB
and we have been specifying APPLICATION_XML for JAXB.
Peter Lacey wrote:
he wants to provide a RESTful means of having the service
validate the credentials. At least that's how I read it.
Right, I understand that. What I'm saying is that I don't think there's
a use case for validating credentials when all that's really needed
is for a
Peter Lacey wrote:
In that I agree. But in my scenario the client of the authenticate
service is the resource being accessed, not the client requesting the
resource. Visually:
CLIENT -- uname/pwd --- RESOURCE -- uname/pwd ---
AUTHENTICATE SERVICE
Right, gotcha. The
Sean,
I agree that HEAD should be supported.
Just for the sake of discussion, however, I personally don't find HEAD
all that interesting in comparison with Conditional GETs.
I mean, when does the client ever just want to see if a resource has
changed (or exists) without actually retrieving
JC wrote:
I am trying to develop a Restful login system.
I have never found a form or url based authentication system that felt
anywhere near as good (or even as RESTful) as using Basic Authentication
over SSL.
First of all, I believe people need to get over this concept of logging
in.
Rob Heittman wrote:
The main reason I've used it is to fetch content-length and make any
necessary provisions (check storage space, warn user, etc.) on the
client side before fetching the representation.
In this case you definitely don't want the whole GET response coming
at ya.
Ya, OK.
this whole silly logging in thing...
;-)
On 10/3/07, Adam Taft [EMAIL PROTECTED] wrote:
JC wrote:
I am trying to develop a Restful login system.
I have never found a form or url based authentication system that felt
anywhere near as good (or even as RESTful) as using Basic Authentication
over SSL
Aron Roberts wrote:
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response.
Would this also imply that the correct HTTP Status code to be returned
from a HEAD request should be 204, corresponding in the Restlet
framework to something
Tom McGee wrote:
Should this in the appicationContext.xml:
bean id=fooResource scope=request class=FooResource /
be this:
bean id=fooResource scope=request class=FooResource
scope=prototype/
It should be either one of two ways:
a) bean id=fooResource scope=request class=FooResource /
b)
factories that does not require CGLib if
your interested.
On 9/13/07, Adam Taft [EMAIL PROTECTED] wrote:
Tom McGee wrote:
Should this in the appicationContext.xml:
bean id=fooResource scope=request class=FooResource /
be this:
bean id=fooResource scope=request class=FooResource
scope
You should check out Terracotta. http://www.terracotta.org/ It does
shared cross-JVM memory management pretty seamlessly. It's open source.
Being the good REST programmer that I am :), I don't keep session state
on the server. But, if I had to do it, they have a really slick way to
I guess I was reading the question as more like: Are sessions secure?
or Are cookies secure? Not so much is any generic technology secure?
My answer to the sessions/cookies question:
Cookies and/or sessions cannot ever be secure without SSL. Otherwise, a
man-in-the-middle can use the
Justin Makeig wrote:
Am I missing something?
No, you're not missing anything. I think it just depends on your
goals/setup/platform/etc.
In my setup, it looks like this (from top down):
Restlets (routers, filters, authenticators, etc.)
My Custom Finder
Anonymous Inner Class Resource
Kim,
One of the bigger problems you'll have (in my opinion) is integration
of Restlet's Resource classes within your Spring framework. A Restlet
Resource will generally be the class you'll want talking to your spring
backend (like your spring DAOs, etc.). However, the Resource instances
mostly be wired via spring.
Jon
Adam Taft wrote:
Kim,
One of the bigger problems you'll have (in my opinion) is
integration of Restlet's Resource classes within your Spring
framework. A Restlet Resource will generally be the class you'll want
talking to your spring backend (like your spring
Alex,
The only resolve I found was to switch to Jetty. I didn't do anything
more, as I couldn't determine whose fault it was (restlet or simple).
I'd suggest using Jetty.
Adam
Alex Milowski wrote:
On 6/4/07, Adam Taft [EMAIL PROTECTED] wrote:
I've discovered a problem with the Simple
I do a POST without an entity, and I think there are valid use cases for
it (albeit these are edge cases).
In order to do so, I had to override the handlePost() method to accept
empty request bodies (bypassing that isEntityAvailable() check).
I don't think there's anything unrestful in
Sean Landis wrote:
Adam Taft adam at adamtaft.com writes:
[... deleted ...]
I'm assuming you're using a web browser client, because an adjustment
to an existing resource would imply PUT, right? But, as we know,
PUT/DELETE sucks on web browsers.
The operation is not idempotent so
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
Sean Landis wrote:
The nature of the data is
a clientId and a callId. These are going to be used for governance and
should be part of every call in our environment. It seemed to me that
since it was not application related, that it ought to be hidden. I'd love
to hear about alternatives
Based on what you wrote Adam, it sounds like you would agree that using
hidden parameters in this case doesn't break REST. Now that I've explained
what we are trying to accomplish, can you suggest a more RESTful
approach? We are very interested in being as RESTful as possible.
Sounds like
solution might be better.
Anyway, good point.
Avi Flax wrote:
On 7/18/07, Adam Taft [EMAIL PROTECTED] wrote:
I like the webdav status code use, 102 Processing. Seems very
appropriate.
Sorry to come into this late, but this caught my eye. If this is a
RESTful web service, wouldn't HTTP's 202
the slashes for this case.
Later,
Adam
Adam Taft wrote:
Erik Hetzner wrote:
That is a hierarchy, so it should use slashes. Longitude,latitude is
not a hierarchy but a tuple, and they suggest for this commas.
So:
Longitude,Latitude == Latitude,Longitude ??
I'm legitimately asking. It does
Erik Hetzner wrote:
Which is of greater significance: the language translated from or
language translated to? If you can’t answer that question, and I don’t
think that you can, then you don’t have a hierarchy.
Which is greater significance: manufacturer, model year, model class,
model type?
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
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
Erik Hetzner wrote:
You beat me to it! Just to add, the RWS book suggests using commas for
ordered pairs in the URI design section, which makes sense to me.
Really?? That's weird. Wrong even?
I mean, if you can (or should) use commas, we'd have urls like this:
Michael Terrington wrote:
Ordered does not necessarily mean hierarchical.
Hierarchy == Ordered, in my mind (particularly as it involves REST).
I mean, if we're talking about Hierarchy in the object oriented frame of
mind (ie. IS A type hierarchy), then maybe you have something. But,
we're
Michael Terrington wrote:
Absolutely, either is valid. I prefer to keep related things at the same level of hierarchy (i.e. the same folder).
Say there's thousands of these, would you still have them in one folder?
Hundreds of thousands? At which point do you change your thinking?
Jason Hudgins wrote:
This begs the question though, are these list resources really all that useful?
Well, I think even though you haven't found a usefulness for those URLs
yet, doesn't mean that they may not be useful in the future.
Using a more natural organization for your data will
Erik Hetzner wrote:
That is a hierarchy, so it should use slashes. Longitude,latitude is
not a hierarchy but a tuple, and they suggest for this commas.
So:
Longitude,Latitude == Latitude,Longitude ??
I'm legitimately asking. It does in real life, right? Same with things
like x,y
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
that the createResource method creates a new anonymous inner
Resource class and then delegates the appropriate methods to the interface.
I hope this helps someone. Jerome, please feel free to post this to the
wiki if you want.
Adam
/*
* Author: Adam Taft - [EMAIL PROTECTED]
* License: Public Domain
Jerome,
Is this change going to be seen in the 1.0.x line? I was looking for it
in 1.0.2, but not seeing it. I need Vary: Authorization header support
as well (I need it for a different reason, however).
Also, due to lack of support, how do I add to Vary header? I'm calling:
Form
Philip,
After you have explored this issue, it would be helpful (at least to me,
but I'm sure to others) to describe your approach, and even your source
code if possible. The information you put together would be a good
addition to the wiki.
Your prototype may pave the way for a integrated
://www.restlet.org/documentation/1.0/faq#24
Best regards,
Jerome
-Message d'origine-
De : Adam Taft [mailto:[EMAIL PROTECTED]
Envoyé : samedi 16 juin 2007 02:16
À : discuss@restlet.tigris.org
Objet : Preventing Greedy URL Matching
Hi,
I'm sure this has got to be a FAQ for Restlet, so sorry
Stian,
Great question / conversation starter...
You're right, this seems to be a common problem that every REST
developer has to work with. Having some level of support for resource
list generation in RESTlet would be nice.
I don't really have any new ideas for you, as I have to generate
Generally, when one wants a list in REST style, you have two options:
/user/?additionalparameters
/users/additional/parameters/
Either way allows you to have /user/{ID}/ as a valid url.
I don't know enough about the RESTlet API to tell you, but I think your
{ID} will likely eat your /list/
Ok, weird. Thanks for the confirmation. I'll try and investigate some
more when I get a chance. Who knows, it may be something weird with my
server or something.
I'm WinXP and Java 6. What are you?
I think I'm using the more recent restlet binaries, but maybe I'll pull
from SVN just to
Thierry,
It's funny that I can very easily reproduce the problem. Using the test
case I provided, the minimal setup (only the required restlet related
jars), using Restlet 1.01, etc. With Apache Bench, it's real obvious
there are problems.
I switched to Asyncweb to try it out. However,
Jim Alateras wrote:
My point is, what is the /cars URL (without the query string) going to
return to the user?? It should be defined to return some list and the
query string parameters will modify the default criteria for said list.
/cars will return all car resources (i.e unconstrained) the
to
CONNECTOR_INTERNAL_ERROR (as discussed before). I hope this will satisfy
you. Otherwise, let us know or reopen the bug report.
Best regards,
Jerome
-Message d'origine-
De : Adam Taft [mailto:[EMAIL PROTECTED]
Envoyé : dimanche 3 juin 2007 04:10
À : discuss@restlet.tigris.org
Objet : Re: Please
the problem is more
around not setting the response status code on failure.
cheers
/jima
Adam Taft wrote:
Here's a test case to look at...
public class TestClass {
public static void main(String[] args) {
try {
Request request = new Request(Method.GET
Bryan,
I know this isn't directly answering your question, but how we do
testing is by integrating with the Spring Framework. With Spring, you
get various DAO and service layer support classes which are easily testable.
Essentially, if you make your Restlets as dumb as possible by
Jim,
This has to do with what I noticed about the Client eating exceptions.
Basically, what's happening is that some of the Client methods, like
handle(), wrap certain exceptions in order to log them. However, they
don't rethrow the exceptions.
So, if you pass in a dud URL like you
The biggest concern for me is that IOException is being eaten in the
client. So, for example, an illegal url or a host not found error is
being trapped, logged and then no other error is being thrown. Yuck.
There's no appropriate status code which can model a host not found
exception,
Yes, I've read all that. Those links are well known. But please
carefully read from the link you provided...
Stian Soiland wrote:
http://radio.weblogs.com/0122027/2003/08/15.html Commons Logging was
my fault
If you're building a stand-alone application, don't use
commons-logging. If
a
worthy goal for adoption of the project.
Adam
Piyush Purang wrote:
Hi Adam,
We already had a discussion on this topic.
See http://thread.gmane.org/gmane.comp.java.restlet/905/focus=937
Cheers
Piyush
On 5/24/07, Adam Taft [EMAIL PROTECTED] wrote:
Yes, I've read all that. Those links
John D. Mitchell wrote:
IIUC your need, the user ID should be in the URL proper since that's
what is used to identify the specific resource. I.e.,
/users/johnm/...
Right, that's actually a good point. It's possible that the best url
scheme for the original poster is someting like:
John D. Mitchell wrote:
On 5/23/07, Adam Taft [EMAIL PROTECTED] wrote:
John D. Mitchell wrote:
[...]
However, I find them useful for optional stuff for non-GET requests,
too.
Do you have a use case for this? I'm genuinely curious.
?output={html,xhtml,json,etc.}
It's optional
Here's a test case to look at...
public class TestClass {
public static void main(String[] args) {
try {
Request request = new Request(Method.GET,
a);
Client client = new
I'm sure this has come up before... Is there interest doing logging via
the Apache Commons Logging facility? It's such a standard on other
projects that it is likely already installed in most deployments of
restlet. It's a bit frustrating to have a logging facility configured
(like log4j)
Hi,
I'm trying to set a StatusService object on a Component. In my custom
StatusService object, I'm overriding the getStatus() method so that I
can do some custom handling based on various exceptions being thrown in
our restlets and resources.
If I call Component#setStatusService, the
, like content negotiation, but
that may be worth it, maybe.
Best regards,
Jerome
-Message d'origine-
De : Adam Taft [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 17 mai 2007 06:21
À : discuss@restlet.tigris.org
Objet : Resource Thread Safety Question
Hi,
I know that in normal use, Resource
Hi,
I know that in normal use, Resource instances are created per request.
However, I'm curious about the thread safety issues involved. If I have
a singleton Resource class, are there any potential problems with this?
For example, is calling getRequest() thread safe?
I'm using
57 matches
Mail list logo
