Re: GET and POST - Semantics vs. Function
I concur. -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." --Einstein On Sep 14, 2009, at 11:41 AM, Rob Heittman wrote: > Quick pragmatic security note on this: > > I actually disagree with this statement. Using GET to pass login > parameters is fine, and in some cases preferable (particularly as it > relates to client caching). If you're concerned about security, you > should encrypt such requests using SSL (you really should do this > regardless of the method used in this case). > > Most web servers include the full URL of each request in their > server logs. These logs are not always automatically treated with > the privacy accorded to the password database. This is one reason > that many prefer to send such data via POST, since entity bodies are > not typically recorded except in debugging situations. > > - Rob > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394703
Re: GET and POST - Semantics vs. Function
I see where you are coming from. Thank you for your advice. -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." --Einstein On Sep 14, 2009, at 9:41 AM, Stephen Groucutt wrote: > I'm not sure I get where you're coming from exactly. It matters > very much how data is sent to the server, as part of the uniform > interface is the expected server behavior for each HTTP verb. > > If I issue: > > GET /my/resource/12345 > Accept: text/html > ... > > Then I expect to receive resource 12345 in HTML format (or some HTTP > error code that explains why I cannot). > > If I issue: > > POST /my/resource > > > with some entity body of a type described by the Content-Type > header, I expect a Created response with a Location field pointing > to the new resource (or some HTTP error code that explains why the > resource could not be created). I would not expect a GET issued > with an entity body to do anything useful with that entity body, nor > would I expect a POST issued with no body to create anything useful, > unless the resource was of a certain type that required no input > data to be created. These assumptions allow me, as a consumer of > that RESTful resource, to interact with that resource without having > to do anything special. > > You can, of course, define a resource that ignores these conventions > and does its own thing. You'll just lose the benefit of offering a > uniform interface to consumers of that resource - and when you start > needing clients to do custom, non-standard things, you're one step > closer to the old WSDL/SOAP thing. > > On Mon, Sep 14, 2009 at 9:44 AM, Schley Andrew Kutz > wrote: > Dave, > > Thank you for your input; it is much appreciated. I'm just bothered by > the fact that GET and POST have a data delivery mechanism tied to them > in addition to their semantic purpose of immutable and modifiable > actions. It would seem to me that the method by which you send data to > the server should not dictate what the server does to that data. > > -- > -a > > "Only two things are infinite, the universe and human stupidity, and > I'm not sure about the former." --Einstein > > On Sep 14, 2009, at 3:22 AM, David Bordoley wrote: > > > Hi Andrew, > > > > It might be more useful if you could supply a more detailed example > > that is causing you headaches. Really the difference between POST > and > > GET is idempotence. GET operations must be idempotent, not having > side > > effects, while POST operations may have side effects as defined by > the > > server. A good rule of thumb is that if a request returns data but > > doesn't change the state of the server, than GET should be used as > it > > allows for sane client/intermediary caching. > > > > On Sat, Sep 12, 2009 at 12:21 PM, Schley Andrew Kutz > > wrote: > >> I'm faced with a dilemma. I'm trying to be a good RFC consumer and > >> stick with the true purpose of GET and POST (see > >> http://www.cs.tut.fi/~jkorpela/forms/methods.html > >> for a good discussion on the history of these two HTTP verbs). > >> Plainly put, GET is for retrieving data and POST is for creating > >> data. > >> However, the problem lies in the fact that their purpose and their > >> data encoding mechanism are mutually exclusive. GET requests encode > >> data in the URL and POST requests encode data into the form. > However, > >> it is not always desirable to issue a GET request with URL-encoded > >> data (login information for example), not is it always desirable to > >> POST data with a form (sometimes a query string will do). > > > > I actually disagree with this statement. Using GET to pass login > > parameters is fine, and in some cases preferable (particularly as it > > relates to client caching). If you're concerned about security, you > > should encrypt such requests using SSL (you really should do this > > regardless of the method used in this case). > > > > Also the URI RFC doesn't require that URI parameters be form > encoded. > > You could as easily pass JSON, XML, etc. in the query string as long > > as it is properly escaped. Form encoding for these parameters is > > typically chosen as a pragmatic decision due to HTML. > > > > Dave > > > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394479 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394618 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394648
REST and Authentication
Not to start a fire, but I was curious what people thought about my approach to authentication with my RESTful application. I am currently using a Restlet authenticator (was using a Servlet filter) to authenticate incoming requests. Once authenticated the request and response have a cookie added to their cookie collection. This cookie is also stored in an authentication tokens table the REST application has access to. The benefit of this is that it allows for a "login once" architecture without having to deal with the hazards of BASIC auth (never expiring for example). However, I am pretty sure I am violating the spirit of REST by maintaining a form of state. What do you think? -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." --Einstein -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394659
Re: GET and POST - Semantics vs. Function
Dave, Thank you for your input; it is much appreciated. I'm just bothered by the fact that GET and POST have a data delivery mechanism tied to them in addition to their semantic purpose of immutable and modifiable actions. It would seem to me that the method by which you send data to the server should not dictate what the server does to that data. -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." --Einstein On Sep 14, 2009, at 3:22 AM, David Bordoley wrote: > Hi Andrew, > > It might be more useful if you could supply a more detailed example > that is causing you headaches. Really the difference between POST and > GET is idempotence. GET operations must be idempotent, not having side > effects, while POST operations may have side effects as defined by the > server. A good rule of thumb is that if a request returns data but > doesn't change the state of the server, than GET should be used as it > allows for sane client/intermediary caching. > > On Sat, Sep 12, 2009 at 12:21 PM, Schley Andrew Kutz > wrote: >> I'm faced with a dilemma. I'm trying to be a good RFC consumer and >> stick with the true purpose of GET and POST (see >> http://www.cs.tut.fi/~jkorpela/forms/methods.html >> for a good discussion on the history of these two HTTP verbs). >> Plainly put, GET is for retrieving data and POST is for creating >> data. >> However, the problem lies in the fact that their purpose and their >> data encoding mechanism are mutually exclusive. GET requests encode >> data in the URL and POST requests encode data into the form. However, >> it is not always desirable to issue a GET request with URL-encoded >> data (login information for example), not is it always desirable to >> POST data with a form (sometimes a query string will do). > > I actually disagree with this statement. Using GET to pass login > parameters is fine, and in some cases preferable (particularly as it > relates to client caching). If you're concerned about security, you > should encrypt such requests using SSL (you really should do this > regardless of the method used in this case). > > Also the URI RFC doesn't require that URI parameters be form encoded. > You could as easily pass JSON, XML, etc. in the query string as long > as it is properly escaped. Form encoding for these parameters is > typically chosen as a pragmatic decision due to HTML. > > Dave > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394479 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394618
GET and POST - Semantics vs. Function
I'm faced with a dilemma. I'm trying to be a good RFC consumer and stick with the true purpose of GET and POST (see http://www.cs.tut.fi/~jkorpela/forms/methods.html for a good discussion on the history of these two HTTP verbs). Plainly put, GET is for retrieving data and POST is for creating data. However, the problem lies in the fact that their purpose and their data encoding mechanism are mutually exclusive. GET requests encode data in the URL and POST requests encode data into the form. However, it is not always desirable to issue a GET request with URL-encoded data (login information for example), not is it always desirable to POST data with a form (sometimes a query string will do). I'm curious what others think of the differences between GET and POST and whether it is still desirable to think of them as separate verbs or rather just two means to accomplish the same thing with different encoding techniques. Thanks! -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." --Einstein -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394107
Questions about Security Model
I was hoping someone could provide me a little more insight into the workings of the Restlet security model. I'm currently using M4 and have created my own Authenticator filter that uses JAAS to do authentication. I notice that there is also a class called Verifier (which JaasVerifier appears to be a sub-class of), as well as Enrollers, Subjects, Principals, etc. However, the flow chart at http://www.restlet.org/documentation/2.0/tutorial (see attached image) explains how Filters are used (and I deduced how to use them from the guard example -- very nice routing mechanism -- similar to how IIS handles requests -- I like how it isolates logical steps -- authenticate, authorize, process, post, etc.), but it makes no mention of Verifiers or the other classes in the security namespace. I would love it if I could get a crash course in how to properly handle security within the Restlet API. Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2393515<>I was hoping someone could provide me a little more insight into the workings of the Restlet security model. I'm currently using M4 and have created my own Authenticator filter that uses JAAS to do authentication. I notice that there is also a class called Verifier (which JaasVerifier appears to be a sub-class of), as well as Enrollers, Subjects, Principals, etc. However, the flow chart at http://www.restlet.org/documentation/2.0/tutorial (see attached image) explains how Filters are used (and I deduced how to use them from the guard example -- very nice routing mechanism -- similar to how IIS handles requests -- I like how it isolates logical steps -- authenticate, authorize, process, post, etc.), but it makes no mention of Verifiers or the other classes in the security namespace. I would love it if I could get a crash course in how to properly handle security within the Restlet API. Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2393515
Re: Help! -- Error handler isn't working
I changed the package name last night :(
http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/hyper9/vangaea/server/rest/BaseResource.java?view=markup
Here is the updated link. Thanks!
--
-a
"Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former." -- Einstein
On Jul 25, 2009, at 6:01 AM, Jerome Louvel wrote:
> Hi Schley,
>
> I could open your link (404). By default, the exception doesn't
> appear in the browser to not expose too much internal details. You
> can customize the StatusService if needed.
>
> I agree it would be nice to have such an option available so I've
> updated this RFE:
>
> "Return clear status description when exception caught"
> http://restlet.tigris.org/issues/show_bug.cgi?id=852
>
> 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
> Envoyé : jeudi 23 juillet 2009 01:07
> À : discuss@restlet.tigris.org
> Objet : Re: Help! -- Error handler isn't working
>
> Jerome,
>
> Sorry about that (updated). Here is the ViewVC link to the file -
> http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/h9labs/vangaea/server/rest/BaseResource.java?view=markup
> .
>
> I've updated the code to take advantage of M4's doCatch handler.
> However, when I throw a ResourceException in the doInit() method, or
> any method, the ResourceException is not being displayed in the
> browser, and I was under the impression that it should.
>
> Thanks!
>
> --
> -a
>
> "Only two things are infinite, the universe and human stupidity, and
> I'm not sure about the former." -- Einstein
>
> On Jul 21, 2009, at 2:53 AM, Jerome Louvel wrote:
>
>> Hi Schley,
>>
>> Could you send us your project (or a snippet reproducing the issue)
>> and
>> Restlet environment details (version, OS, etc.)? It should
>> definitely work.
>>
>> BTW, I suggest that you use more meaningful email title when you
>> post,
>> easier for tracking and searching in the archives.
>>
>> 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
>> Envoyé : mardi 14 juillet 2009 21:52
>> À : discuss@restlet.tigris.org
>> Objet : Help!
>>
>> The StringRepresentation returned by 'public Representation handle()'
>> is no longer appearing in the browser when I access my server.
>>
>> Here is an example:
>>
>> @Override
>>public Representation handle()
>>{
>>if (true) return new StringRepresentation("Hello, world.");
>>...
>>
>> That should ALWAYS trump any other logic and show Hell, world. in the
>> browser. Was a bug introduced to the Maven snapshot? Or do you
>> think I
>> could have farked myself somehow.
>>
>> --
>> -a
>>
>> "Ideally, a code library must be immediately usable by naive
>> developers, easily customized by more sophisticated developers, and
>> readily extensible by experts." -- L. Stein
>>
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23713
>> 20
>>
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372837
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2374613
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2375508
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2375517
Re: Help! -- Error handler isn't working
Jerome,
Sorry about that (updated). Here is the ViewVC link to the file -
http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/h9labs/vangaea/server/rest/BaseResource.java?view=markup
.
I've updated the code to take advantage of M4's doCatch handler.
However, when I throw a ResourceException in the doInit() method, or
any method, the ResourceException is not being displayed in the
browser, and I was under the impression that it should.
Thanks!
--
-a
"Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former." -- Einstein
On Jul 21, 2009, at 2:53 AM, Jerome Louvel wrote:
> Hi Schley,
>
> Could you send us your project (or a snippet reproducing the issue)
> and
> Restlet environment details (version, OS, etc.)? It should
> definitely work.
>
> BTW, I suggest that you use more meaningful email title when you post,
> easier for tracking and searching in the archives.
>
> 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
> Envoyé : mardi 14 juillet 2009 21:52
> À : discuss@restlet.tigris.org
> Objet : Help!
>
> The StringRepresentation returned by 'public Representation handle()'
> is no longer appearing in the browser when I access my server.
>
> Here is an example:
>
> @Override
> public Representation handle()
> {
> if (true) return new StringRepresentation("Hello, world.");
> ...
>
> That should ALWAYS trump any other logic and show Hell, world. in the
> browser. Was a bug introduced to the Maven snapshot? Or do you think I
> could have farked myself somehow.
>
> --
> -a
>
> "Ideally, a code library must be immediately usable by naive
> developers, easily customized by more sophisticated developers, and
> readily extensible by experts." -- L. Stein
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23713
> 20
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372837
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2374613
Re: bug?
Gotcha. Thanks. -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jul 15, 2009, at 12:43 PM, Jerome Louvel wrote: > Hi Schley, > > For Maven refresh policy, please check: > http://www.restlet.org/downloads/maven > > For Restlet 2.0 M4, I'd like to push it out by the end of the month. > > 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 : Schley Andrew Kutz [mailto:sak...@gmail.com] > Envoyé : vendredi 10 juillet 2009 20:41 > À : discuss@restlet.tigris.org > Objet : Re: bug? > > Jerome, > > Do you know when this will make it into the Maven snapshot? Thanks! > > -- > -a > > "Ideally, a code library must be immediately usable by naive > developers, easily customized by more sophisticated developers, and > readily extensible by experts." -- L. Stein > > On Jul 7, 2009, at 3:04 AM, Jerome Louvel wrote: > >> Actually, I've just renamed the method to "doCatch" as the "error" >> term was ambiguous regarding Java terminology (ie. errors vs >> exceptions). Same logic. >> >> 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 : Schley Andrew Kutz [mailto:sak...@gmail.com] >> Envoyé : dimanche 5 juillet 2009 15:45 >> À : discuss@restlet.tigris.org >> Objet : Re: bug? >> >> Great! I'm really looking forward to this and the OnError bit making >> it into a release. :) >> >> -- >> -a >> >> "Ideally, a code library must be immediately usable by naive >> developers, easily customized by more sophisticated developers, and >> readily extensible by experts." -- L. Stein >> >> On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote: >> >>> Hi Schley, >>> >>> FYI, this has been fixed in SVN trunk. >>> >>> Best regards, >>> Jerome Louvel >>> -- >>> Restlet ~ Founder and Lead developer ~ http://www.restlet.org >>> Noelios Technologies ~ Co-founder ~ http://www.noelios.com >>> >>> >>> Schley Andrew Kutz a écrit : >>>> I want to prevent the use of HTTP VERB annotations in order to >>>> force >>>> sub-classes to respond with specific class types via abstract >>>> methods >>>> that I prototype in a base class. I marked the isAnnotated() method >>>> as >>>> @Override and final and returned false. However, when it returns >>>> false >>>> I get the following error: >>>> >>>> java.lang.NullPointerException >>>>at >>>> org >>>> .restlet >>>> .engine >>>> .resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: >>>> 106) >>>>at >>>> org >>>> .restlet.resource.ServerResource.getAnnotation(ServerResource.java: >>>> 649) >>>>at >>>> org.restlet.resource.ServerResource.doHandle(ServerResource.java: >>>> 329) >>>>at >>>> org >>>> .restlet >>>> .resource.ServerResource.doNegotiatedHandle(ServerResource.java: >>>> 592) >>>>at >>>> org >>>> .restlet >>>> .resource.ServerResource.doConditionalHandle(ServerResource.java: >>>> 260) >>>>at org.restlet.resource.ServerResource.handle(ServerResource.java: >>>> 921) >>>>at >>>> com >>>> .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: >>>> 159) >>>>at org.restlet.resource.Finder.handle(Finder.java:510) >>>>at org.restlet.routing.Filter.doHandle(Filter.java:156) >>>>at org.restlet.routing.Filter.handle(Filter.java:201) >>>>at org.restlet.routing.Router.handle(Router.java:490) >>>>at org.restlet.routing.Filter.doHandle(Filter.java:156) >>>>at org.restlet.routing.Filter.handle(Filter.java:201) >>>>at org.restlet.routing.Filter.doHandle(Filter.java:156) >>>>at org.restlet.routing.Filter.handle(Filter.java:201) >>>>at org.restlet
Help!
The StringRepresentation returned by 'public Representation handle()'
is no longer appearing in the browser when I access my server.
Here is an example:
@Override
public Representation handle()
{
if (true) return new StringRepresentation("Hello, world.");
...
That should ALWAYS trump any other logic and show Hell, world. in the
browser. Was a bug introduced to the Maven snapshot? Or do you think I
could have farked myself somehow.
--
-a
"Ideally, a code library must be immediately usable by naive
developers, easily customized by more sophisticated developers, and
readily extensible by experts." -- L. Stein
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2371320
Re: bug?
Jerome, Do you know when this will make it into the Maven snapshot? Thanks! -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jul 7, 2009, at 3:04 AM, Jerome Louvel wrote: > Actually, I've just renamed the method to "doCatch" as the "error" > term was ambiguous regarding Java terminology (ie. errors vs > exceptions). Same logic. > > 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 : Schley Andrew Kutz [mailto:sak...@gmail.com] > Envoyé : dimanche 5 juillet 2009 15:45 > À : discuss@restlet.tigris.org > Objet : Re: bug? > > Great! I'm really looking forward to this and the OnError bit making > it into a release. :) > > -- > -a > > "Ideally, a code library must be immediately usable by naive > developers, easily customized by more sophisticated developers, and > readily extensible by experts." -- L. Stein > > On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote: > >> Hi Schley, >> >> FYI, this has been fixed in SVN trunk. >> >> Best regards, >> Jerome Louvel >> -- >> Restlet ~ Founder and Lead developer ~ http://www.restlet.org >> Noelios Technologies ~ Co-founder ~ http://www.noelios.com >> >> >> Schley Andrew Kutz a écrit : >>> I want to prevent the use of HTTP VERB annotations in order to force >>> sub-classes to respond with specific class types via abstract >>> methods >>> that I prototype in a base class. I marked the isAnnotated() method >>> as >>> @Override and final and returned false. However, when it returns >>> false >>> I get the following error: >>> >>> java.lang.NullPointerException >>> at >>> org >>> .restlet >>> .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: >>> 106) >>> at >>> org >>> .restlet.resource.ServerResource.getAnnotation(ServerResource.java: >>> 649) >>> at >>> org.restlet.resource.ServerResource.doHandle(ServerResource.java: >>> 329) >>> at >>> org >>> .restlet >>> .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) >>> at >>> org >>> .restlet >>> .resource.ServerResource.doConditionalHandle(ServerResource.java: >>> 260) >>> at org.restlet.resource.ServerResource.handle(ServerResource.java: >>> 921) >>> at >>> com >>> .h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: >>> 159) >>> at org.restlet.resource.Finder.handle(Finder.java:510) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Router.handle(Router.java:490) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at >>> org >>> .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: >>> 153) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) >>> at >>> org >>> .restlet >>> .engine.application.ApplicationHelper.handle(ApplicationHelper.java: >>> 71) >>> at org.restlet.Application.handle(Application.java:396) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Router.handle(Router.java:490) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.routing.Router.handle(Router.java:490) >>> at org.restlet.routing.Filter.doHandle(Filter.java:156) >>> at org.restlet.routing.Filter.handle(Filter.java:201) >>> at org.restlet.engine.
Re: bug?
Great! I'm really looking forward to this and the OnError bit making it into a release. :) -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jul 5, 2009, at 8:20 AM, Jerome Louvel wrote: > Hi Schley, > > FYI, this has been fixed in SVN trunk. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > Schley Andrew Kutz a écrit : >> I want to prevent the use of HTTP VERB annotations in order to force >> sub-classes to respond with specific class types via abstract methods >> that I prototype in a base class. I marked the isAnnotated() method >> as >> @Override and final and returned false. However, when it returns >> false >> I get the following error: >> >> java.lang.NullPointerException >> at >> org >> .restlet >> .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java: >> 106) >> at >> org >> .restlet.resource.ServerResource.getAnnotation(ServerResource.java: >> 649) >> at org.restlet.resource.ServerResource.doHandle(ServerResource.java: >> 329) >> at >> org >> .restlet >> .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) >> at >> org >> .restlet >> .resource.ServerResource.doConditionalHandle(ServerResource.java:260) >> at org.restlet.resource.ServerResource.handle(ServerResource.java: >> 921) >> at >> com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: >> 159) >> at org.restlet.resource.Finder.handle(Finder.java:510) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Router.handle(Router.java:490) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at >> org >> .restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: >> 153) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) >> at >> org >> .restlet >> .engine.application.ApplicationHelper.handle(ApplicationHelper.java: >> 71) >> at org.restlet.Application.handle(Application.java:396) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Router.handle(Router.java:490) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.routing.Router.handle(Router.java:490) >> at org.restlet.routing.Filter.doHandle(Filter.java:156) >> at org.restlet.routing.Filter.handle(Filter.java:201) >> at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) >> at org.restlet.Component.handle(Component.java:397) >> at org.restlet.Server.handle(Server.java:350) >> at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) >> at >> org >> .restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: >> 149) >> at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: >> 932) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: >> 487) >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: >> 362) >> at >> org >> .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: >> 216) >> at >> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: >> 181) >> at >> org >> .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: >> 216) >> at >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: >> 729) >> at org.mortbay.jetty.webapp.WebAppContext.h
bug?
I want to prevent the use of HTTP VERB annotations in order to force sub-classes to respond with specific class types via abstract methods that I prototype in a base class. I marked the isAnnotated() method as @Override and final and returned false. However, when it returns false I get the following error: java.lang.NullPointerException at org .restlet .engine.resource.AnnotationUtils.getAnnotation(AnnotationUtils.java:106) at org.restlet.resource.ServerResource.getAnnotation(ServerResource.java: 649) at org.restlet.resource.ServerResource.doHandle(ServerResource.java: 329) at org .restlet .resource.ServerResource.doNegotiatedHandle(ServerResource.java:592) at org .restlet .resource.ServerResource.doConditionalHandle(ServerResource.java:260) at org.restlet.resource.ServerResource.handle(ServerResource.java:921) at com.h9labs.vangaea.server.rest.BaseResource.handle(BaseResource.java: 159) at org.restlet.resource.Finder.handle(Finder.java:510) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java: 153) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org .restlet .engine.application.ApplicationHelper.handle(ApplicationHelper.java:71) at org.restlet.Application.handle(Application.java:396) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:490) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:111) at org.restlet.Component.handle(Component.java:397) at org.restlet.Server.handle(Server.java:350) at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java: 149) at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java: 932) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org .mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java: 49) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 505) at org.mortbay.jetty.HttpConnection $RequestHandler.headerComplete(HttpConnection.java:829) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 395) at org.mortbay.thread.QueuedThreadPool $PoolThread.run(QueuedThreadPool.java:488) -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2365418
Architecture question
I have moved my application from sub-classing Restlets to sub-classing Resources and am now relying on annotations to process incoming requests (@Get for ex.). However, one of the nice side-effects of processing requests with the catch-all handle method is that it allows me to have one place to catch exceptions. My question is this: Is there a way to catch all exceptions with one method (an onError event handler for ex.) so that I can decide what to do with them there? Thanks! -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2365092
Re: How do I get the contents of POST variables?
Jerome, Wonderful, thank you. I am about to release a rather interesting open source project that makes LARGE use of Restlet, and I am glad to get your help. -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jun 19, 2009, at 1:56 PM, Jerome Louvel wrote: > Hi Schley, > > As Thierry said, we do want to make sure the developer understands > what's > going on. But, there is a way in Restlet to deal with all three > uniformly. > > In Restlet 1.1, it was a bit hidden as you need to look at the Route > instance returned when you call attach*() methods on a Router. In > Restlet > 2.0 you have a new org.restlet.routing.Extractor filter. > > Both classes have those methods: > - extractCookie(String attribute, String cookieName, boolean first) > - extractEntity(String attribute, String parameter, boolean first) > - extractQuery(String attribute, String parameter, boolean first) > > Once this filter is called, it extracts specified cookies, query and > entity > params into the request attributes which can be processed uniformly > down the > road by your resource classes. > > Does it solve your issue better? > > 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 : Schley Andrew Kutz [mailto:sak...@gmail.com] > Envoyé : vendredi 19 juin 2009 13:41 > À : discuss@restlet.tigris.org > Objet : Re: How do I get the contents of POST variables? > > I thought that the entity is what I should be looking at, thanks! > > I know that they are different, but some frameworks already provide a > single call to fetch the data, and I have found it useful in the past. > > -- > -a > > "Ideally, a code library must be immediately usable by naive > developers, easily customized by more sophisticated developers, and > readily extensible by experts." -- L. Stein > > On Jun 19, 2009, at 5:08 AM, Thierry Boileau wrote: > >> Hello, >> >> if "entity" is the Representation sent via the POST request, you can >> parse it with a Form as follow: >> Form form = new Form(entity); >> >> If you want to get the cookies values, just call request#getCookies. >> >> For sure, there is a real distinction between the query part of an >> URI >> and the content of POSTed entity. >> The query is part of the identifier of the resource. An entity sent >> via >> a POST is a set of data that the resource is asked to take into >> account >> in order to act on its current state. >> It seems preferable keep this distinction. >> >> best regards, >> Thierry Boileau >>> I can get GET variables via the getQueryAsForm method for a resource >>> reference, but how do I get POST variables? Also, it would be nice >>> to >>> have a getVariable() method that returned a series comprised of GET, >>> POST, and COOKIE keys and values. >>> >>> Thanks! >>> >>> >> >> -- >> > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23634 > 64 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23634 > 89 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363631 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363635
Re: How do I get the contents of POST variables?
I thought that the entity is what I should be looking at, thanks! I know that they are different, but some frameworks already provide a single call to fetch the data, and I have found it useful in the past. -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein On Jun 19, 2009, at 5:08 AM, Thierry Boileau wrote: > Hello, > > if "entity" is the Representation sent via the POST request, you can > parse it with a Form as follow: > Form form = new Form(entity); > > If you want to get the cookies values, just call request#getCookies. > > For sure, there is a real distinction between the query part of an URI > and the content of POSTed entity. > The query is part of the identifier of the resource. An entity sent > via > a POST is a set of data that the resource is asked to take into > account > in order to act on its current state. > It seems preferable keep this distinction. > > best regards, > Thierry Boileau >> I can get GET variables via the getQueryAsForm method for a resource >> reference, but how do I get POST variables? Also, it would be nice to >> have a getVariable() method that returned a series comprised of GET, >> POST, and COOKIE keys and values. >> >> Thanks! >> >> > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363464 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363489
How do I get the contents of POST variables?
I can get GET variables via the getQueryAsForm method for a resource reference, but how do I get POST variables? Also, it would be nice to have a getVariable() method that returned a series comprised of GET, POST, and COOKIE keys and values. Thanks! -- -a "Ideally, a code library must be immediately usable by naive developers, easily customized by more sophisticated developers, and readily extensible by experts." -- L. Stein -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363366
