On Fri, Jan 14, 2011 at 4:28 PM, Mark Machielsen <Mark.Machielsen at gxsoftware.com> wrote: > Hi, > > For several projects we need an search and index service with a REST > interface. This needs to be tenantaware service and a tenant may define > several indices.
IMHO a generic index/search service would be a realy nice addon to the Amdatu stack! :) > Proposal for the REST interface (the index is the resource): > - GET calls: > ?- /rest/index/[indexname]/?q=... ?: search in index according to query > ?- /rest/index/ ? ? ? ? ? ? ? ? ? ?: list of all indices Assuming List of URIs of all indices. The hierarchial nature of the URIs is / should be of second interest and a client should not break is this were to be changed. > ?- /rest/index/[indexname]/schema ?: schema of the index > - POST calls: > ?- /rest/index/[indexname] ? ? ? ? : creates an index with index name as > identifier This is kind of ambiguous. I think a more common pattern is posting the desired name as data. The service would then issue a HTTP/1.1 301 Moved Permanently specifying the URI of the newly created resource through the location field. The hierarchial nature of the URIs is / should be of second interest and a client should not break is this were to be changed. > - PUT calls: > ?- /rest/index/[indexname]/ ? ? ? ?: update the index (eg adding a document) > ?- /rest/index/[indexname]/schema ?: updates the schema of the index Assuming the service would then issue a HTTP/1.1 302 Found with the updated recources URI in the Location field? > - DELETE calls: > ?- /rest/index/[indexname] ? ? ? ? : deletes index > > Implementation will be Solr embedded in an OSGi bundle. Remarks: > - admin webinterface is not included. Only interface is a REST interface > - default JSON interface (/solr/select?q=...) will be removed > - authorization will be added > - REST interface as described above will be added Assuming all HTTP response code to be added for failure scenario's > I suppose this will be a new subproject for Amdatu? Yes > Do we agree on this REST interface? As a first concept.. yes +1. Besides my comments above I would like a to know where we are going in terms of REpresentation. Specific to this use case, but may also more general. Will we be supporting loosly typed JSON as a default and/or should ew consider more stringly typed XML (as well)? > Are there use cases where this REST interface is insufficient? All I can think of is management operations (compress / backup / .. ), but we have not yet set on a mechanism for that anyway. I can imagine we would not go with REST interfaces for those types of operations. Regards, Bram
