Difference between revisions of "Talk:MetadataSearchAPI"
(→Metadata Search API Discussion page) |
(→Metadata Search API Discussion page) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 19: | Line 19: | ||
Use case:<br /> | Use case:<br /> | ||
Mobile Client send object search request with a specific location coodinates (X, Y) to retrieve pictures which are near to (e.g. distance less than D km) that location.<br /> | Mobile Client send object search request with a specific location coodinates (X, Y) to retrieve pictures which are near to (e.g. distance less than D km) that location.<br /> | ||
| + | |||
| + | add a new query expression with function name and metadata name or ordered names as function arguments<br /> | ||
| + | |||
e.g. distance(attrX, attrY) < delta<br /> | e.g. distance(attrX, attrY) < delta<br /> | ||
OR: distance(attrXY) < delta | OR: distance(attrXY) < delta | ||
| + | |||
| + | |||
| + | |||
| + | <big>Suggestion about HTTP Headers</big> | ||
| + | |||
| + | In current spec, No HTTP Headers are described. | ||
| + | So, for strictly, I suggest to describe clearly such as "No Request Headers are required." | ||
| + | |||
| + | And, For providing more useful information to client applications, I suggest to define the spec about HTTP Response Header. | ||
| + | Especially, I suggest to define headers about the numbers related to the query, such as SoftLayer API. | ||
| + | |||
| + | Examples of the definition of response headers are as follows: | ||
| + | {| class="wikitable" | ||
| + | |- | ||
| + | ! Response Header !! Description | ||
| + | |- | ||
| + | | X-OSMS-Items-Total || The total number of items matched to the search query | ||
| + | |- | ||
| + | | X-OSMS-Items-Count || The number of items included in the response | ||
| + | |} | ||
| + | |||
| + | |||
| + | <big>Suggestion about HTTP Response Code</big> | ||
| + | |||
| + | In current spec, No HTTP Response codes are defined. | ||
| + | So I suggest to define the response codes for each API operation status. | ||
| + | |||
| + | Examples of the definition of response codes are as follows: | ||
| + | {| class="wikitable" | ||
| + | |- | ||
| + | ! Response Code !! Description | ||
| + | |- | ||
| + | | 200 OK || The operation was success normally. | ||
| + | |- | ||
| + | | 400 Bad Request || Query Syntax Error. | ||
| + | |- | ||
| + | | 403 Forbidden || The user had no authority. It mean the user must have the special role as "authorized searchers" if the user need to search. | ||
| + | |- | ||
| + | |rowspan="3"| 404 Not Found || The requested accounts,containers or objects you search were not found. | ||
| + | |- | ||
| + | | The requested endpoint or version not found. (Ex: The requested <OSMS API version> is "v2", but the implementation is supported only "v1") | ||
| + | |- | ||
| + | | The requested item as marker was not found. | ||
| + | |- | ||
| + | |rowspan="2"| 405 Method Not Allow || Searching was not available. | ||
| + | |- | ||
| + | | The requested metadata is not available. | ||
| + | |- | ||
| + | | 500 Internal Server Error || Some Error on the search system. | ||
| + | |} | ||
| + | |||
| + | |||
| + | <big> Suggestion about Data Types </big><br/> | ||
| + | |||
| + | The proposal suggests each attribute has one of 3 types: string, numeric, date. How do we deduce the type for user metadata attributes i.e. object_meta_<name> attributes ? This is important for range searches since types such as dates are not sorted correctly when represented as strings. This seems to warrant a configuration file which contains schema information. In addition, using attribute naming conventions could help set the default behavior e.g. object-meta-start-date-d could refer to a date by default since it has the suffix -d. Also, additional types which seem important are a floating point type and a type for representing geo-spatial coordinates and/or general spatial information. Ideally the set of types which can be handled should be extensible. | ||
| + | |||
| + | <big> Suggestion regarding System Metadata </big><br/> | ||
| + | Regarding system metadata, many attributes are part of this proposal which are not currently part of Swift. There should be a minimal set of attributes - probably those attributes which are part of Swift - which should be available for indexing by all vendor implementations. Other than that, different vendors would have different requirements for generating new system metadata for indexing, and it probably shouldn't be a mandatory part of the API. Also, in general, the user should be able to control which user and system metadata attributes are indexed in order to control the amount of resources invested in metadata indexing/search. | ||
Latest revision as of 12:34, 2 September 2014
Metadata Search API Discussion page
Feel free to add general questions, comments, suggestions, etc. to this page. You can also edit the API page for comments about specific portions of the API. Interested parties will be watching these Wiki pages and will get emails of updates.
Suggestion about Sorting
add asceding '+' and desceding '-' syntax to give more choice for user to control search results.
sorted[=<attr1>[,<attr2>,…]] --> sorted[=<attr1[+|-]>[,<attr2[+|-]>,…]]
- if attributes without + or -, it is as-is defined by current spec.
- if attributes with + or -, the sorting results will be ascedant or descedant.
Suggestion about location based search capability
Use case:
Mobile Client send object search request with a specific location coodinates (X, Y) to retrieve pictures which are near to (e.g. distance less than D km) that location.
add a new query expression with function name and metadata name or ordered names as function arguments
e.g. distance(attrX, attrY) < delta
OR: distance(attrXY) < delta
Suggestion about HTTP Headers
In current spec, No HTTP Headers are described. So, for strictly, I suggest to describe clearly such as "No Request Headers are required."
And, For providing more useful information to client applications, I suggest to define the spec about HTTP Response Header. Especially, I suggest to define headers about the numbers related to the query, such as SoftLayer API.
Examples of the definition of response headers are as follows:
| Response Header | Description |
|---|---|
| X-OSMS-Items-Total | The total number of items matched to the search query |
| X-OSMS-Items-Count | The number of items included in the response |
Suggestion about HTTP Response Code
In current spec, No HTTP Response codes are defined. So I suggest to define the response codes for each API operation status.
Examples of the definition of response codes are as follows:
| Response Code | Description |
|---|---|
| 200 OK | The operation was success normally. |
| 400 Bad Request | Query Syntax Error. |
| 403 Forbidden | The user had no authority. It mean the user must have the special role as "authorized searchers" if the user need to search. |
| 404 Not Found | The requested accounts,containers or objects you search were not found. |
| The requested endpoint or version not found. (Ex: The requested <OSMS API version> is "v2", but the implementation is supported only "v1") | |
| The requested item as marker was not found. | |
| 405 Method Not Allow | Searching was not available. |
| The requested metadata is not available. | |
| 500 Internal Server Error | Some Error on the search system. |
Suggestion about Data Types
The proposal suggests each attribute has one of 3 types: string, numeric, date. How do we deduce the type for user metadata attributes i.e. object_meta_<name> attributes ? This is important for range searches since types such as dates are not sorted correctly when represented as strings. This seems to warrant a configuration file which contains schema information. In addition, using attribute naming conventions could help set the default behavior e.g. object-meta-start-date-d could refer to a date by default since it has the suffix -d. Also, additional types which seem important are a floating point type and a type for representing geo-spatial coordinates and/or general spatial information. Ideally the set of types which can be handled should be extensible.
Suggestion regarding System Metadata
Regarding system metadata, many attributes are part of this proposal which are not currently part of Swift. There should be a minimal set of attributes - probably those attributes which are part of Swift - which should be available for indexing by all vendor implementations. Other than that, different vendors would have different requirements for generating new system metadata for indexing, and it probably shouldn't be a mandatory part of the API. Also, in general, the user should be able to control which user and system metadata attributes are indexed in order to control the amount of resources invested in metadata indexing/search.
