> The main reason for this is that there are several apis that (for > example) accept PUT requests without a payload (even if that makes > little sense, being purists), meaning we should assume not all apis > are 100% RESTful. Given this, I'd rather be flexible here, and don't > require PATCH requests to have a payload.
Yeah I totally agree that put validation on the payload by default is not a good idea as the flexibility is more important in here. Thanks for the comment Ignasi :) 2013/12/12 Ignasi Barrera <ignasi.barr...@gmail.com> > > I tried PATCH annotation and it is not fully working. What I got is that > I > > can create a HTTP PATCH request if no payload is attached (which doesn't > > make much sense since it always need some body to specify what you want > to > > update > > The payload is set in the request in this method [1], when parsing the > invoked method annotations, reading its parameters and calling the > binders. > > There is currently no validation that requires a payload to be > included in POST/PUT methods, and I think we shouldn't validate by > default that a payload is present when sending PATCH requests (it is > up to the one making the api call to properly build the request). > > The main reason for this is that there are several apis that (for > example) accept PUT requests without a payload (even if that makes > little sense, being purists), meaning we should assume not all apis > are 100% RESTful. Given this, I'd rather be flexible here, and don't > require PATCH requests to have a payload. > > > > > [1] > https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/rest/internal/RestAnnotationProcessor.java#L181 > > > On 12 December 2013 16:59, Ignacio Mulas Viela <immulasvi...@gmail.com> > wrote: > > Hi All, > > I tried PATCH annotation and it is not fully working. What I got is that > I > > can create a HTTP PATCH request if no payload is attached (which doesn't > > make much sense since it always need some body to specify what you want > to > > update). So my problem was mainly how allow the PATCH annotation to > attach > > a body to the request. > > I saw that the payload attachment is handled in [1] but could not go into > > more details. :) > > > > I have tried with HTTP but not with HTTPS so I do not know if there is > > special extra requirements in there. > > > > [1] > > > https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java > > > > > > 2013/12/12 Ignasi Barrera <ignasi.barr...@gmail.com> > > > >> For the record: https://issues.apache.org/jira/browse/JCLOUDS-405 > >> > >> On 12 December 2013 16:23, Ignasi Barrera <ignasi.barr...@gmail.com> > >> wrote: > >> > Verified with the Charles proxy that the fix works. Will send the PR > >> > as soon as tests finish :) > >> > > >> > On 12 December 2013 15:58, Ignasi Barrera <ignasi.barr...@gmail.com> > >> wrote: > >> >> Trying it right now... Will send a PR if it works > >> >> > >> >> On 12 December 2013 15:36, Ignasi Barrera <ignasi.barr...@gmail.com> > >> wrote: > >> >>> I found this comment [1] in the Jersey issue, explaining that in SSL > >> >>> there is an HTTPS URL connection wrapping the actual > HttpURLConnection > >> >>> where the method should be set. > >> >>> Could you do a quick test and add the appropriate bits from the code > >> >>> in the Jersey issue and see if that does the trick for HTTPS > >> >>> connections? > >> >>> > >> >>> > >> >>> [1] > >> > https://java.net/jira/browse/JERSEY-639?focusedCommentId=370981&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_370981 > >> >>> > >> >>> On 12 December 2013 15:30, Everett Toews < > everett.to...@rackspace.com> > >> wrote: > >> >>>> Yes. The request is going to > >> https://ord.queues.api.rackspacecloud.com. > >> >>>> > >> >>>> There's some special handling for HTTPS [1] but the part for > setting > >> the request method seems to be common for both HTTP and HTTPS. > >> >>>> > >> >>>> What did you have in mind? > >> >>>> > >> >>>> Everett > >> >>>> > >> >>>> [1] > >> > https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L158 > >> >>>> > >> >>>> > >> >>>> On Dec 12, 2013, at 2:29 AM, Ignasi Barrera wrote: > >> >>>> > >> >>>>> This is strange. The reflection fix is the same used in the Jersey > >> >>>>> client [1], and it is supposed to work. > >> >>>>> Looking at the jclouds code, there is no special handling for > HTTPS > >> >>>>> connections. Everett, are you using an HTTPS one? > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> [1] https://java.net/jira/browse/JERSEY-639 > >> >>>>> > >> >>>>> On 12 December 2013 09:09, Andrew Phillips <aphill...@qrmedia.com > > > >> wrote: > >> >>>>>>> I know that HttpURLConnection.setRequest() [2] doesn't allow > >> PATCH. I > >> >>>>>>> also know that we work around this in jclouds by setting the > field > >> by > >> >>>>>>> reflection [3]. > >> >>>>>> > >> >>>>>> > >> >>>>>> Have you been able to try this with the apachehc [1] driver? Does > >> that make > >> >>>>>> any difference? > >> >>>>>> > >> >>>>>> ap > >> >>>>>> > >> >>>>>> [1] > https://github.com/jclouds/jclouds/tree/master/drivers/apachehc > >> >>>> > >> >
