Merge pull request #90 from ripple/gh-pages

Dev Portal from Staging to Master for 10/30 EXTRA STAGE

gateway_services_spec.md

@@ -15,12 +15,12 @@ All names, URLs, and addresses in this document are used for example purposes on
 | ------- | ----------- | -------- | -------- |
 | [host-meta](#host-meta) | Provides useful metadata about a gateway or service provider, and lists all service endpoints provided by the domain | [RFC6415](http://tools.ietf.org/html/rfc6415) | [ripple.txt](https://ripple.com/wiki/Ripple.txt) |
 | [webfinger](#webfinger) | Performs reverse lookup of Ripple addresses, and lists service endpoints for interacting with a specified account holder | [RFC7033](http://tools.ietf.org/html/rfc7033) | [Federation Name Lookup](https://ripple.com/wiki/Federation_protocol) |
-| [bridge-payments](#bridge-payments) | Plans payments from any Ripple-connected wallet to any other, connecting through gateways as necessary. | [Ripple-REST payments](http://dev.ripple.com/ripple-rest.html#payments) | [Bridge protocol](https://ripple.com/wiki/Services_API) |
+| [bridge-payments](#bridge-payments) | Plans payments from any Ripple-connected wallet to any other, connecting through gateways as necessary. | [Ripple-REST payments](ripple-rest.html#payments) | [Bridge protocol](https://ripple.com/wiki/Services_API) |
 | user-account | Provides standard method for registering an account with a Gateway, and provides signed claims about a user's identity  similar to bridge-payment's required claims | [OpenID Connect Claims](http://openid.net/specs/openid-connect-core-1_0.html#Claims), [JWT](http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25) | -- |
-| wallet-payment | Makes outgoing payments and monitors for incoming payments, and works with hosted wallets. | [Ripple-REST payments](http://dev.ripple.com/ripple-rest.html#payments) | -- |
-| wallet-info | Shows information about a wallet, and works with hosted wallets | [Ripple-REST accounts](http://dev.ripple.com/ripple-rest.html#accounts) | -- |
-| wallet-balances | Shows information about balances in multiple currencies, and works with hosted wallets. | [Ripple-REST accounts](http://dev.ripple.com/ripple-rest.html#accounts) | -- |
-| wallet-history | Shows history of payments sent and received, and works with hosted wallets. | [Ripple-REST payment history](http://dev.ripple.com/ripple-rest.html#payment-history) | -- |
+| wallet-payment | Makes outgoing payments and monitors for incoming payments, and works with hosted wallets. | [Ripple-REST payments](ripple-rest.html#payments) | -- |
+| wallet-info | Shows information about a wallet, and works with hosted wallets | [Ripple-REST accounts](ripple-rest.html#accounts) | -- |
+| wallet-balances | Shows information about balances in multiple currencies, and works with hosted wallets. | [Ripple-REST accounts](ripple-rest.html#accounts) | -- |
+| wallet-history | Shows history of payments sent and received, and works with hosted wallets. | [Ripple-REST payment history](ripple-rest.html#payment-history) | -- |
 
 ## Event Sequence ##
 

gatewayd.md

@@ -166,10 +166,10 @@ Depending on your situation, there are some configuration variables you can set:
  * Gatewayd comes with a self-signed certificate for SSL pre-configured. This is adequate for development use. 
  * For production use, you should set the `SSL_KEY_PATH` and `SSL_CERTIFICATE_PATH` settings to point at a certificate purchased from a trusted [CA](http://en.wikipedia.org/wiki/Certificate_authority).
 * The `BASIC_AUTH` option (on by default) defines whether or not the REST API requires a password to connect. We recommend *always* using this. 
- * The `KEY` option (not defined by default) sets the API key used for Basic Auth. The username is required to be "admin@<em>yourdomain.com</em>", based Gatewayd's `DOMAIN` setting, and the API key is the password. [In the future](https://github.com/ripple/gatewayd/compare/no-username-auth), you will be able to authenticate by sending the API key as either the username or the password and leaving the other field blank.
+ * The `KEY` option (not defined by default) sets the API key used for Basic Auth. You can authenticate by sending the API key as either the username or password. ([Previous versions](https://github.com/ripple/gatewayd/commit/e8a0767aab80b0605f7334b8e1a6b1578e67cea9) required the username to be "admin@<em>yourdomain.com</em>", based Gatewayd's `DOMAIN` setting, and the API key is the password.
  * You can generate a new `KEY` value with the [Set API Key](#set-api-key) method. (Use the commandline version if it's your first time.)
 
-__*Exception:*__ Gatewayd's HTTP server also serves a `ripple.txt` response that imitates a text file, but is actually dynamically generated based on its current configuration. This route is intended to be public, and is not protected even when BASIC_AUTH is enabled. However, it is disabled if the `HTTP_SERVER` option is disabled.
+__*Exception:*__ Gatewayd's HTTP server also serves a `ripple.txt` response that imitates a text file, but is actually dynamically generated based on its current configuration. This route is intended to be public, and is not protected even when `BASIC_AUTH` is enabled. However, it is disabled if the `HTTP_SERVER` option is disabled.
 
 Gatewayd implements authentication using the [Passport Node.js Module](http://passportjs.org/), so if you are familiar with Passport, you can easily customize the authentication scheme for Gatewayd to fit your needs.
 [[Source]<br>](https://github.com/ripple/gatewayd/blob/master/lib/http/passport_auth.js "Source")

js/apitool-rest.js

@@ -117,7 +117,7 @@ Request('Update Account Settings', {
 Request('Prepare Payment', {
     method: GET,
     path: '/v1/accounts/{:source_address}/payments/paths/{:destination_address}/{:amount}?{:query_params}',
-    description: 'Change the current settings for the given Ripple account',
+    description: 'Retrieve possible payment objects for a desired payment',
     link: '#prepare-payment',
     params: {
         "{:source_address}": DEFAULT_ADDRESS_1,
@@ -216,7 +216,7 @@ Request("Grant Trustline", {
 Request("Check Notifications", {
     method: GET,
     path: "/v1/accounts/{:address}/notifications/{:hash}",
-    description: "Browse through the history of payments sent and received by an account",
+    description: "Monitor an account for all kinds of transactions",
     link: "#check-notifications",
     params: {
         "{:address}": DEFAULT_ADDRESS_1,

ripplerest_api.md

@@ -388,7 +388,7 @@ Accounts are the core unit of authentication in the Ripple Network. Each account
 
 
 
-## Generate Account ##
+## Generate Wallet ##
 
 (New in [Ripple-REST v1.3.0](https://github.com/ripple/ripple-rest/releases/tag/v1.3.0-rc4))
 
@@ -402,7 +402,8 @@ GET /v1/wallet/new
 ```
 </div>
 
-[Try it! >](rest-api-tool.html#generate-wallet)
+[Try it! >](rest-api-tool.html#generate-account)
+<!-- not a typo; waiting for the tool to be updated -->
 
 There are two steps to making a new account on the Ripple network: randomly creating the keys for that account, and sending it enough XRP to meet the account reserve.
 
@@ -1409,7 +1410,13 @@ Notifications are sorted in order of when they occurred, so you can save the mos
 
 Get a notification for the specific transaction hash, along with links to previous and next notifications, if available.
 
-__`GET /v1/accounts/{:address}/notifications/{:transaction_hash}`__
+<div class='multicode'>
+*REST*
+
+```
+GET /v1/accounts/{:address}/notifications/{:transaction_hash}
+```
+</div>
 
 [Try it! >](rest-api-tool.html#check-notifications)
 

tx_format.md

@@ -547,7 +547,7 @@ A trust line indicates an issuer you trust enough to accept their issuances as p
 
 Existing offers are grouped by "quality", which is measured as the ratio between `TakerGets` and `TakerPays`. Offers with a higher quality are taken preferentially. (That is, the person accepting the offer receives as much as possible for the amount of currency they pay out.) Offers with the same quality are taken on the basis of which offer was placed in the earliest ledger version.
 
-When offers of the same quality are placed in the same ledger version, the order in which they are taken is determined by the [canonical order](https://github.com/ripple/rippled/blob/f65cea66ef99b1de149c02c15f06de6c61abf360/src/ripple/app/misc/CanonicalTXSet.cpp "Source: Transaction ordering") in which the transactions were [applied to the ledger](https://github.com/ripple/rippled/blob/develop/src/ripple/app/consensus/LedgerConsensus.cpp#L1404-L1507 "Source: Applying transactions"). This behavior is designed to be deterministic, efficient, and hard to game.
+When offers of the same quality are placed in the same ledger version, the order in which they are taken is determined by the [canonical order](https://github.com/ripple/rippled/blob/f65cea66ef99b1de149c02c15f06de6c61abf360/src/ripple/app/misc/CanonicalTXSet.cpp "Source: Transaction ordering") in which the transactions were [applied to the ledger](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source: Applying transactions"). This behavior is designed to be deterministic, efficient, and hard to game.
 
 ### Expiration ###