Skip to main content
Outside service Partner
Hitachi Vantara Knowledge

Object representation


HCP represents objects differently based on the namespace access protocol the client is using.

Object representation with HTTP

With HTTP, HCP represents each object as a URL. The root of the object path in the URL is always rest.

Here’s an example of the URL for an object named wind.jpg in the images directory in a namespace named climate in a tenant named geo in an HCP system named hcp.example.com:

http://climate.geo.hcp.example.com/r...mages/wind.jpg

Users and applications represent system metadata and identify custom metadata by using query parameters appended to the URLs. HCP returns system metadata in HTTP response headers and returns custom metadata in the format in which it was originally specified.

For more information on object representation with HTTP , see Using a Namespace.

Object representation with the S3 compatible API

With the S3 compatible API, HCP represents each object as a URL. The exact format of this URL depends on how the application used to access the object handles user authentication.

The S3 compatible API does not have the concept of directories. Slashes in object names are simply part of the name and are not directory separators. Thus, objects with the S3 compatible API do not have paths.

Here’s an example of one of the possible URLs for an object named
images/wind.jpg in a namespace named climate in a tenant named geo in an HCP system named hcp.example.com:

http://climate.geo.hcp.example.com/h...mages/wind.jpg

Users and applications represent system and custom metadata by using HTTP request headers. HCP returns system and custom metadata in HTTP response headers.

For more information on object representation with the S3 compatible API, see Forward slashes in object names.

Object representation with the HSwift API

With the HSwift API, HCP represents each object as a URL. The exact format of this URL depends on how the application used to access the object handles user authentication.

HSwift does not have the concept of directories. Slashes in object names are simply part of the name and are not directory separators. Thus, objects in HSwift do not have paths.

Here’s an example of one of the possible URLs for an object named
images/fire.jpg in a namespace named climate in a tenant named geo in an HCP system named hcp.example.com:

http://api.climate.geo.hcp.example.c...mages/fire.jpg

Users and applications represent system and custom metadata by using HTTP request headers. HCP returns system and custom metadata in HTTP response headers.

For more information on object representation with the HSwift API, see Using the HCP OpenStack HSwift API.

Object representation with other namespace access protocols

For namespace access protocols other than the HTTP and S3 compatible APIs, HCP includes a standard POSIX file system called HCP-FS that represents each object as a set of files. One of these files has the same name as the object. This file contains the fixed-content data. When downloaded or opened, this file has the same content as the originally stored item.

The other files that HCP-FS presents contain object metadata. These files, most of which are plain text, are called metafiles.

All files containing fixed-content data are in a directory hierarchy headed by data. All metafiles are in a directory hierarchy headed by metadata.

With this view of objects as conventional files and directories, HCP supports routine file-level calls and enables users and applications to find fixed-content data in familiar ways.

For more information on object representation with protocols other than the HTTP and S3 compatible APIs, see Using a Namespace.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.