standardize capitalization: ReST -> REST
source: http://en.wikipedia.org/wiki/Representational_state_transfer Change-Id: If35339d1dc663c5b07a23bf62cb551bb29fe8037
This commit is contained in:
parent
721b256f52
commit
b6a28b0093
2
.gitignore
vendored
2
.gitignore
vendored
@ -1,3 +1,3 @@
|
||||
.DS_STORE?
|
||||
.DS_Store
|
||||
target/
|
||||
*.xpr
|
||||
|
@ -462,7 +462,7 @@
|
||||
familiar with: </para>
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>ReSTful web services</para>
|
||||
<para>RESTful web services</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>HTTP/1.1</para>
|
||||
@ -565,7 +565,7 @@
|
||||
<chapter xml:id="General_API_Information-d1e436">
|
||||
<title>General API Information</title>
|
||||
<para>
|
||||
The OpenStack Compute API is defined as a ReSTful HTTP
|
||||
The OpenStack Compute API is defined as a RESTful HTTP
|
||||
service. The API takes advantage of all aspects of the
|
||||
HTTP protocol (methods, URIs, media types, response codes,
|
||||
etc.) and providers are free to use existing features of
|
||||
@ -874,10 +874,10 @@ X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb
|
||||
<title>Efficient Polling with the
|
||||
<parameter>Changes-Since</parameter> Parameter</title>
|
||||
<para>
|
||||
The ReST API allows you to poll for the status of
|
||||
The REST API allows you to poll for the status of
|
||||
certain operations by performing a &GET; on various
|
||||
elements. Rather than re-downloading and re-parsing
|
||||
the full status at each polling interval, your ReST
|
||||
the full status at each polling interval, your REST
|
||||
client may use the
|
||||
<parameter>changes-since</parameter> parameter to
|
||||
check for changes since a previous request. The
|
||||
|
@ -188,7 +188,7 @@
|
||||
Authenticate to generate a token.
|
||||
</p>
|
||||
<p xmlns="http://www.w3.org/1999/xhtml">
|
||||
This call will return a token if successful. Each ReST request against other services (or other
|
||||
This call will return a token if successful. Each REST request against other services (or other
|
||||
calls on Keystone such as the GET /tenants call)
|
||||
requires the inclusion of a specific authorization token HTTP x-header, defined as X-Auth-Token.
|
||||
Clients obtain
|
||||
@ -196,12 +196,12 @@
|
||||
Keystone Service and supplying valid credentials.
|
||||
</p>
|
||||
<p xmlns="http://www.w3.org/1999/xhtml">
|
||||
Client authentication is provided via a ReST interface using the POST method,
|
||||
Client authentication is provided via a REST interface using the POST method,
|
||||
with v2.0/tokens supplied as the path. A payload of credentials must be included
|
||||
in the body.
|
||||
</p>
|
||||
<p xmlns="http://www.w3.org/1999/xhtml">
|
||||
The Keystone Service is a ReSTful web service. It is the entry point to all service APIs.
|
||||
The Keystone Service is a RESTful web service. It is the entry point to all service APIs.
|
||||
To access the Keystone Service, you must know URL of the Keystone service.
|
||||
</p>
|
||||
</doc>
|
||||
|
@ -131,7 +131,7 @@
|
||||
Compute defaults to being configured to use the Image Service. With an OpenStack Image
|
||||
Service server in place, the Image Service fetches the image on to the host machine and
|
||||
then OpenStack Compute boots the image from the host machine. To place images into the
|
||||
service, you would use a ReST interface to stream them, and the service, in turn,
|
||||
service, you would use a REST interface to stream them, and the service, in turn,
|
||||
streams that into a back end which could be S3, OpenStack Object Storage (which can use
|
||||
an S3), or the local file system on the server where OpenStack Image Service is
|
||||
installed.</para>
|
||||
|
@ -80,7 +80,7 @@
|
||||
<para>Operations are the actions you perform within an OpenStack Object Storage system such
|
||||
as creating or deleting containers, uploading or downloading objects, and so on. The
|
||||
full list of operations is documented in the Developer Guide. Operations may be
|
||||
performed via the ReST web service API or a language-specific API; currently, we support
|
||||
performed via the REST web service API or a language-specific API; currently, we support
|
||||
Python, PHP, Java, Ruby, and C#/.NET.</para>
|
||||
<important>
|
||||
<para> All operations must include a valid authorization token from your authorization system. </para>
|
||||
@ -91,7 +91,7 @@
|
||||
<title>Language-Specific API Bindings</title>
|
||||
<para>A set of supported API bindings in several popular languages are available from the
|
||||
Rackspace Cloud Files product, which uses OpenStack Object Storage code for its
|
||||
implementation. These bindings provide a layer of abstraction on top of the base ReST
|
||||
implementation. These bindings provide a layer of abstraction on top of the base REST
|
||||
API, allowing programmers to work with a container and object model instead of working
|
||||
directly with HTTP requests and responses. These bindings are free (as in beer and as in
|
||||
speech) to download, use, and modify. They are all licensed under the MIT License as
|
||||
|
@ -1484,7 +1484,7 @@ net.ipv4.netfilter.ip_conntrack_max = 262144
|
||||
<para>At first, a simple approach of deleting an account through completely external
|
||||
calls was considered as it required no changes to the system. All data would
|
||||
simply be deleted in the same way the actual user would, through the public
|
||||
ReST API. However, the downside was that it would use proxy resources and log
|
||||
REST API. However, the downside was that it would use proxy resources and log
|
||||
everything when it didn't really need to. Also, it would likely need a
|
||||
dedicated server or two, just for issuing the delete requests.</para>
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user