I know.... we're doing CRUD (Create/Read/Update/Delete) mapped to HTTP and we need to do complex GET's for our bindings...
The argument for sticking to any method, say POST, because it can do everything, is OK, unless you logically want do use separate methods, but; if the API is already interpreting the binding for you, with regards to application usage of the protocol, then your hands are tied. It's no big deal... I just hate it when API designers make a decision to force a certain behavior, without thinking about corner cases... On Aug 20, 1:58 pm, John Patterson <[email protected]> wrote: > On 20 Aug 2010, at 03:27, jwangatx wrote: > > > I know it seems logical that GET's should only send a url with QS > > (Query String) params to qualify the get, but if I have a complex > > subscription/highly-directly query, I would prefer to send all the > > parameters as payload/XML. > > Why not just use POST? -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
