: > On 4/5/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: : >> How about leveraging HTTP 1.1 methods more semantically, such that a : >> PUT is used for an insert perhaps, and a DELETE for a delete, and GET : >> for searches. POST is fine for update semantics.
i was thinking about th PUT/POST distinction for udpates/adds a while back -- but i convinced myself that POST made more sense for updates because the WebDav/REST mentality of PUT is that PUTing to a same URL twice with different content should replace the content -- unless we start having update URLs where the uniqueKey field is in the URL, we aren't really living up to the "PUT" expectation (not to mention the cases where people don't use uniqueKey in their index, or want to update multiple docs at a time) i also realized that except for the people who are really gung-ho about REST, many people don't understand PUT and DELETE .. there are even some HTTP client libraries out there that either don't support them or make them hard to do. so while i like the idea of supporting PUT/DELETE, i'm not certain what the logical semanics should be, and i think the existing POST/GET behavior should definitley remain as is with support for POSTing queries added (so plugins that want to take in large amounts of input can efficiently) : In my copious free time* I will eventually create, unless someone : beats me to it, a Ruby library to wrap the interface to Solr making : it easily palatable to the flood of Rails applications out there that : need what Solr offers. go hard dude. : Additionally, supporting the OpenSearch API would be a fantastic : addition to Solr as well. This is one area I might be actually : tinkering with in the coming weeks/months. I mentioned a while back, this may be entirely possible using an XSLT (and perhaps a custom plugin for complex query parsing) your milage may vary... http://www.mail-archive.com/[email protected]/msg00130.html -Hoss
