I understand the function of -d, but there are two issues here: 1. it works differently locally than on the server, and 2. lots of APIs can and should use GETs with bodies. Maybe the RFCs don't allow it, but sometimes the RFCs don't represent the real world. In the real world, I may want to pass additional data, such as an API key, or something to modify the format of the result: detail=true|false, etc, and I want to give the client the option of putting that data in the body, which makes for cleaner, easier to debug client code (and yes, as a server developer I try to think about the clients). Maybe the GET call would return a lot of data, but the client wants a subset, should the user list include=1&include=3&....include=795 in the URL? no, that's cluttered and therefore harder to debug. Sometimes it's just cleaner to put that in the body, no matter what the RFCs say. LOTS of real-world API's do this, (sundcloud and Indabamusic are two I've worked with).
Moreover, it is very difficult to develop when the local and live versions are different, so at least that much is a bug. Finally, if I am writing an API that, say, always returns XML/JSON, and someone sends a bad request, that, lets face it isn't all that bad, it would be nice if I had the option of returning the result so I could still guarantee them an XML/JSON result. -- 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 google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
