HP StoreAll Storage - Manual (Page 174)

The version field is recommended, but not required. In the syntax descriptions, it is surrounded by
square brackets to indicate that it is optional.
Changes to this API will normally be backward-compatible, and not require any client-side syntax
changes to perform the same operations. However, certain changes might be required in future
API versions that break backward compatibility. In that case, the version is increased to the next
value. Any request without the version field might no longer work as desired or it might return an
error. Any request with the version field and a value less than or equal to the current version, is
handled correctly by the new API version unless the capability has been removed or is beyond the
support lifetime of the product.
API date formats
All date/time values accepted by the API in HTTP requests must be in seconds only (no nanoseconds)
since the UNIX epoch start point, which is:
1 Jan 1970 00:00:00 UTC
In the following example, the user provided the number of seconds that have occurred between
the UNIX epoch and April 17, 2012, 06:09:22 UTC/GMT as the date and time value in an HTTP
request:
1334642962
All dates and times provided in API HTTP responses are in seconds and nanoseconds since the
UNIX epoch start point. For example, the following date/time value as returned by the StoreAll
REST API in a JSON HTTP response:
1334642962.678934883
This signifies the number of seconds since UNIX epoch on April 17, 2012, 06:09:22.678934883
UTC/GMT.
Some of the time fields stored in the inode of the file in the IBRIX file system store a granularity of
seconds only, no nanoseconds. In these cases the nanoseconds portion is returned as zeros (for
example, 1334642962.000000000).
Some of the time fields stored in the metadata database store a granularity of microseconds instead
of nanoseconds. In these cases, the last 3 digits of the nanoseconds portion is returned as zeros
(for example, 1334642962.865449000).
Authentication and permissions
Any user accessing the API must authenticate as one of the valid users or groups configured for
this HTTP share, except for anonymous shares.
For file content transfer operations (see “File content transfer” (page 175) ), including file upload,
download, or deletion, the user must also have permission to perform the file system operation, as
defined by the permissions and ownership of the file and its containing directories. Anonymous
users on anonymous shares can only operate on files that an anonymous user has uploaded using
the HTTP share.
For custom metadata assignment and metadata queries, the user must also have file system
permission to navigate to the directory containing the file or directory defined in the URI. If the user
has that permission, custom metadata assignment and queries will be allowed regardless of the
ownership or permissions of the file or directory. If a directory is specified, the operations will be
allowed on all files and subdirectories regardless of their ownership and permissions. Custom
metadata is stored only in the Express Query database and is not stored with the file or its inode
on the file system. An anonymous user on an anonymous share must have this navigate permission
as the Linux user “daemon” and group “daemon” (daemon:daemon), since that is the user the
HTTP Server acts as, for anonymous operations.
For retention properties assignment, the user must also have file system permission to navigate to
the directory containing the file defined in the URI. Additionally, the user must be the owner of the
file according to the file system’s properties for the file’s owning user. If these permissions are not
174 Express Query