Hello Mark, On 14 Jan 2011, at 16:28 , Mark Machielsen wrote:
> 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. We recently agreed on how to handle tenant aware services, so somehow the initial request needs to be enough to "extract" the tenant ID. This can be for example based on the hostname, but it could also be encoded in the path of the URL, so /rest/[tenantID]/index/etc. Right? > Proposal for the REST interface (the index is the resource): > - GET calls: > - /rest/index/[indexname]/?q=... : search in index according to query Minor detail: I'd remove the trailing '/' to make it: /rest/index/[indexname]?q=... Question: do we explicitly want to deal with 'paging' in the REST interface and if so, how? > - /rest/index/ : list of all indices > - /rest/index/[indexname]/schema : schema of the index > - POST calls: > - /rest/index/[indexname] : creates an index with index name as > identifier This should be a POST call, without the indexname [1], if it's about creating a *new* index. > - PUT calls: > - /rest/index/[indexname]/ : update the index (eg adding a document) Adding an entry to an existing collection should be done with a POST call. Doing a PUT would replace the whole collection with another collection. > - /rest/index/[indexname]/schema : updates the schema of the index Agreed. I have a question though: can you at any point in time completely change the existing schema, replacing it with a new one, or is that something you do once (when creating the index)? If the latter is the case, we need a different mechanism, probably supplying the schema as part of the POST request that creates the new index. > - DELETE calls: > - /rest/index/[indexname] : deletes index Or all indices if you omit the "indexname". > 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 And since all REST interfaces should be based on OSGi services, we have to design that as well. One general question. Do we want to create a new REST interface for Solr, or do we want to abstract away from Solr and create a generic "search" REST interface? I would be in favor of the latter, but we might have to take a critical look to make sure we can implement it differently. > I suppose this will be a new subproject for Amdatu? That makes sense. > Do we agree on this REST interface? See remarks. > Are there use cases where this REST interface is insufficient? See above, internally I think we should also have an OSGi service, but functionally it should probably support the same features. I'm not sure if we have requirements now that go beyond this interface. Perhaps someone else can comment on that. [1] see http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services Greetings, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20110117/093e9e4b/attachment.html
