COPY'> GET'> HEAD'> PUT'> POST'> DELETE'> '> '> ]>

You can perform the following operations for containers: Verb URI Description &GET; /account/container Lists objects. &PUT; /account/container Creates a container. &DELETE; /account/container Deletes a container. &HEAD; /account/container Gets container metadata. X-Newest Set the optional X-newest header to True in HEAD and GET requests to have Object Storage return the latest version of the container. If set to True, Object Storage queries all replicas to return the most recent one. Without this header, Object Storage responds faster after it finds one valid replica. Because setting this header to True is more expensive for the back end, use it only when it is absolutely needed. All operations follow this format: METHOD /v1/<account>/<container> HTTP/1.1

&GET; operations against a storage container name are performed to retrieve a list of objects stored in the container. Additionally, there are a number of optional query parameters that can be used to refine the list results. A request with no query parameters will return the full list of object names stored in the container, up to 10,000 names. Optionally specifying the query parameters will filter the full list and return a subset of objects. limit For an integer value n , limits the number of results to at most n values. marker Given a string value x , return object names greater in value than the specified marker. end_marker Given a string value x , return object names less in value than the specified marker. prefix For a string value x , causes the results to be limited to object names beginning with the substring x . format Specify either json or xml to return the respective serialized response. delimiter For a character c , return all the object names nested in the container (without the need for the directory marker objects). path For a string value x , return the object names nested in the pseudo path. Equivalent to setting delimiter to '/' and prefix to the path with a '/' on the end. A list of objects is returned in the response body, one object name per line. The response will have a 2xx HTTP status code (between 200 and 299 inclusive). If the container does not exist, or if an incorrect account is specified, then a response with a 404 (Not Found) status code will be returned.

If a format=xml or format=json argument is appended to the storage account URL, the service will serve extended object information serialized in the chosen format. Other than the ?format=xml|json parameter, it will return the same status/errors codes. The sample responses below are formatted for readability.

The system returns a maximum of 10,000 object names per request. To retrieve subsequent object names, another request must be made with the 'marker' parameter. The marker indicates where the last list left off and the system returns object names greater than this marker, up to 10,000 again. Note that the ‘marker’ value should be URL encoded prior to sending the HTTP request. If 10,000 is larger than desired, a 'limit' parameter may be given. If the number of object names returned equals the limit given (or 10,000 if no limit is given), it can be assumed there are more object names to be listed. If the container name list is exactly divisible by the limit, the last request has no content. For an example, let's use a listing of five object names: gala grannysmith honeycrisp jonagold reddelicious We'll use a limit of two to show how things work: Because we received two items back, we can assume there are more object names to list. So, we make another request with a marker of the last item returned: Again we have two items returned; there might be more: Now we received less than the limit number of object names, indicating that we have the complete list. By using end_marker we can limit the result set to object names less than the given value.

Although you cannot nest directories in OpenStack Object Storage, you can simulate a hierarchical structure within a single container by adding forward slash characters (/) in the object name. To navigate the pseudo-directory structure, you may use the delimiter query parameter. See the below examples for an illustration. In the example below, the objects reside in a container called backups. Within that container, the objects are organized in a pseudo-directory called photos. Keep in mind that the container name is not displayed in the example, but that it is a part of the object URLs. For instance, the URL of the picture me.jpg is https://storage.swiftdrive.com/v1/CF_xer7_343/backups/photos/me.jpg. To display a list of all the objects in the storage container, use &GET; without a delimiter or prefix. GET /v1/AccountString/backups The system returns status code 2xx (between 200 and 299, inclusive) and the requested list of the objects. photos/animals/cats/persian.jpg photos/animals/cats/siamese.jpg photos/animals/dogs/corgi.jpg photos/animals/dogs/poodle.jpg photos/animals/dogs/terrier.jpg photos/me.jpg photos/plants/fern.jpg photos/plants/rose.jpg Use the delimiter parameter to limit the displayed results. Any character may be used as a delimiter. However, to use delimiter with pseudo-directories, use the parameter slash (/). GET /v1/AccountString/backups?delimiter=/ The system returns status code 2xx (between 200 and 299, inclusive) and the requested matching objects. Because we use the slash, only the pseudo-directory photos/ displays. Keep in mind that the returned values from a slash delimiter query are not real objects. They have a content-type of application/directory and are in the subdir section of json and xml results. photos/ Use the prefix parameter with the delimiter parameter to view the objects inside a pseudo-directory, including further nested pseudo-directories. GET /v1/AccountString/backups?prefix=photos/&delimiter=/ The system returns status code 2xx (between 200 and 299, inclusive) and the objects and pseudo-directories within the top level pseudo-directory. photos/animals/ photos/me.jpg photos/plants/ You can create an unlimited number of nested pseudo-directories. To navigate through them, use a longer prefix parameter coupled with the delimiter parameter. In the sample output below, there is a pseudo-directory called dogs within the pseudo-directory animals. In order to navigate directly to the files contained within dogs, enter the below command. GET /v1/AccountString/backups?prefix=photos/animals/dogs/&delimiter=/ The system returns status code 2xx (between 200 and 299, inclusive) and the objects and pseudo-directories within the nested pseudo-directory. photos/animals/dogs/corgi.jpg photos/animals/dogs/poodle.jpg photos/animals/dogs/terrier.jpg

&PUT; operations against a storage container are used to create that container. Containers are storage compartments for your data. The URL encoded name must be less than 256 bytes and cannot contain a forward slash '/' character. Containers can be assigned custom metadata by including additional HTTP headers on the &PUT; request. The custom metadata is assigned to a container via HTTP headers identified with the X-Container-Meta- prefix. No content is returned. A status code of 201 (Created) indicates that the container was created as requested. Container &PUT; requests are idempotent and a code of 202 (Accepted) is returned when the container already existed. If you request a &PUT; to a container with an X-Container-Meta- prefix in the header, your &GET;/&HEAD; request responses carry the metadata prefix from the container in subsequent requests. Using custom container metadata, you can create information in the header to effectively tag a container with metadata. The container metadata restrictions are the same as object metadata: you can have 4096 bytes maximum overall metadata, 90 distinct metadata items at the most. Each may have a 128 character name length with a maximum of 256 bytes in the value. Any valid UTF-8 encoded string value is allowed for metadata. In addition for custom metadata, we recommend that you URL-encode the header value. However, for non-custom metadata (such as X-Versions-Location), you must UTF-8 encode and then URL-encode values that contain a container or object name. No content is returned. A status code of 201 (Created) indicates that the container was created as requested. Container &PUT; requests are idempotent and a code of 202 (Accepted) is returned if the container existed prior to the request. If you request a &PUT; to a container with an X-Container-Meta- prefix in the header, your &GET;/&HEAD; request responses carry the metadata prefix from the container in subsequent requests.

&DELETE; operations against a storage container permanently remove it. The container must be empty before it can be deleted. A &HEAD; request against the container can be used to determine if it contains any objects. No content is returned. A status code of 2xx (between 200 and 299, inclusive) indicates success, 404 (Not Found) is returned if the requested container was not found, and a 409 (Conflict) if the container is not empty. No response body is generated.

&HEAD; operations against a storage container are used to determine the number of objects, and the total bytes of all objects stored in the container. Since the storage system is designed to store large amounts of data, care should be taken when representing the total bytes response as an integer; when possible, convert it to a 64-bit unsigned integer if your platform supports that primitive type. The HTTP status code will be 2xx (between 200 and 299, inclusive) if the container exists, and 404 (Not Found) if it does not. The object count and utilization are returned in the X-Container-Object-Count and X-Container-Bytes-Used headers respectively.

You may create any custom or arbitrary metadata headers as you find useful. They must, however, take the format X-Container-Meta-. To create or update the arbitrary container metadata, use the &POST; query. Subsequent requests of the same key/value pair overwrites the previous value. No response body is returned. A status code of 2xx (between 200 and 299, inclusive) indicates success; status 404 (Not Found) is returned when the requested container does not exist. To confirm your metadata changes, perform a &HEAD; request on the container. Do not send the metadata in your &HEAD; request.

To delete a metadata header send an empty value for that particular header, such as X-Container-Meta-Book:. If the tool you're using to communicate with Object Storage doesn't support sending empty headers (older versions of curl) send the header "X-Remove-Container-Meta-name: arbitrary value". For example, send a header like X-Remove-Container-Meta-Book: x. The value (x in this example) is ignored. No response body is returned. A status code of 2xx (between 200 and 299, inclusive) indicates success.