This is a draft description of the REST-interface of CLARIN Metadata Service. Especially the response description is very sketchy yet.
Also the @base is an abstract one (more like a namespace). The actual URL is: http://clarin.aac.ac.at/MDService2/
| parameter | value | description |
|---|---|---|
|
format |
One of:
|
|
|
repository |
Default: 1 |
allows to dynamically select one of the available repositories for the queries. |
|
cache |
One of:
|
This is the default application trying to make sense of any parameters that are passed. So that it is possible to bookmark/send a query as a simple URI (REST at its best ;). Sot it accepts the same parameters as the search-interface, but displays the query within the main user-interface.
| parameter | value | description |
|---|---|---|
|
q |
||
|
squery |
just individual terms |
|
|
columns |
cmdIndex (repeating) |
|
|
collection |
||
|
startRecord |
||
|
maximumRecords |
available response representations:
This provides a summary of collections in the repository (it is passed on to getCollections-method of MdRepository)
| parameter | value | description |
|---|---|---|
|
collection |
||
|
maxdepth |
available response representations:
This provides a summary of the xml-structure in the repository (aggregated XML-subtrees) (it is passed on to queryModel-method of MdRepository)
The starting context can be part of the url (template-style) or in the q parameter.
What happens if both are defined?
| parameter | value | description |
|---|---|---|
|
term |
||
|
q |
||
|
maxdepth |
available response representations:
This combines the information from MdRepository (model-interface), Component Registry and optionally Data Category Registry and RelationRegistry providing a summary of the profiles actually used in the repository together with mapping to data-categories.
| parameter | value | description |
|---|---|---|
|
format |
One of:
|
|
|
term |
One of:
|
|
|
q |
||
|
maxdepth |
available response representations:
This is the actual search interface allowing to retrieve MDRecords from the MDRepository.
Main parameter is q expected to be a valid CQL-query. The query is translated into XPath and passed on to the searchRetrieve-method of MDRepository, which already returns a valid (SRU-protocol compliant) searchRetrieveResponse.
| parameter | value | description |
|---|---|---|
|
q |
||
|
squery |
just individual terms |
|
|
columns |
cmdIndex (repeating) |
|
|
collection |
||
|
maxDepth |
||
|
startRecord |
||
|
maximumRecords |
| parameter | value | description |
|---|---|---|
|
maxDepth |
available response representations:
Special method for retrieving a full individual record. It is also translated into XPath (MdSelfLink) and served by the searchRetrieve-method of MDRepository.
| parameter | value | description |
|---|---|---|
|
q |
PID - handle of the record |
|
|
cacheid |
Proposed parameter, to remember the recordset, the record comes in from, to be able, to retrieve it directly from MDService's cache and save the trip to MDRepository (for data, that is already locally available) |
available response representations:
Delivers the configuration-structure. A server profile or an user specific (plus a special "default"-profile for the
anonymous user).
The profiles are stored as xml-files on the server and handed out as JSON-files to the client.
| parameter | value | description |
|---|---|---|
|
type |
One of:
|
available response representations:
Allows to save back the configuration-file.
| parameter | value | description |
|---|---|---|
|
data |
Default: public |
available response representations:
Allows to view the cache-index
Allows to delete/flush (parts of) cache; parameters constraint the part of cache to be deleted; no param means: delete everything
| parameter | value | description |
|---|---|---|
|
cmdIndex |
anyURI (repeating) |
|
| parameter | value | description |
|---|---|---|
|
cmdIndex |
anyURI (repeating) |
|
| parameter | value | description |
|---|---|---|
|
records |
|
| parameter | value | description |
|---|---|---|
|
records |
|