diff options
| author | Waldemar Znoinski <waldemar.znoinski@intel.com> | 2016-02-15 14:42:02 +0000 |
|---|---|---|
| committer | Waldemar Znoinski <waldemar.znoinski@intel.com> | 2016-02-23 11:00:18 +0000 |
| commit | fdd8f0f91ede06814e3537206234224e9f982e35 (patch) | |
| tree | 3a450959696b8c00f6b58711cef771b95f80bf6c /api-guide/source/faults.rst | |
| parent | c20fbc44a9ece80b4ec8dea10300064a1b5dddc4 (diff) | |
| download | nova-fdd8f0f91ede06814e3537206234224e9f982e35.tar.gz | |
Fix API Guide doc
* typos
* reduntant words
* reworded sentences for clarity
Closes-bug: #1545748
Change-Id: I0700d04de38b34cf13988490873b8c34dad1005b
Diffstat (limited to 'api-guide/source/faults.rst')
| -rw-r--r-- | api-guide/source/faults.rst | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/api-guide/source/faults.rst b/api-guide/source/faults.rst index 0f10fa4350..29bb677013 100644 --- a/api-guide/source/faults.rst +++ b/api-guide/source/faults.rst @@ -2,16 +2,16 @@ Faults ====== -This doc looks at how to understand what has happened to your API request. +This doc explains how to understand what has happened to your API request. Every HTTP request has a status code. 2xx codes signify the API was a success. However, that is often not the end of the story. That generally only means the -request to start the operation has been accepted, it does not mean the action +request to start the operation has been accepted. It does not mean the action you requested has successfully completed. Tracking Errors by Request ID -============================== +============================= Every request made has a unique Request ID. This is returned in a response header. @@ -70,15 +70,15 @@ information about the fault in the body of the response. } } -The error code is returned in the body of the response for convenience. -The message section returns a human-readable message that is appropriate -for display to the end user. The details section is optional and may +The error ``code`` is returned in the body of the response for convenience. +The ``message`` section returns a human-readable message that is appropriate +for display to the end user. The ``details`` section is optional and may contain information—for example, a stack trace—to assist in tracking -down an error. The detail section might or might not be appropriate for +down an error. The ``details`` section might or might not be appropriate for display to an end user. The root element of the fault (such as, computeFault) might change -depending on the type of error. The following is a list of possible +depending on the type of error. The following link contains a list of possible elements along with their associated error codes. For more information on possible error code, please see: @@ -100,7 +100,7 @@ When a server is placed into an ``ERROR`` state, a fault is embedded in the offending server. Note that these asynchronous faults follow the same format as the synchronous ones. The fault contains an error code, a human readable message, and optional details about the error. Additionally, asynchronous -faults may also contain a created timestamp that specifies when the fault +faults may also contain a ``created`` timestamp that specifies when the fault occurred. |