Link to new api

CHANGELOG.md

@@ -79,7 +79,7 @@ FEATURES:
 * **KV Import/Export CLI:** `consul kv export` and `consul kv import` can be used to move parts of the KV tree between disconnected consul clusters, using JSON as the intermediate representation. [GH-2633]
 * **Node Metadata:** Support for assigning user-defined metadata key/value pairs to nodes has been added. This can be viewed when looking up node info, and can be used to filter the results of various catalog and health endpoints. For more information, see the [Catalog](https://www.consul.io/docs/agent/http/catalog.html), [Health](https://www.consul.io/docs/agent/http/health.html), and [Prepared Query](https://www.consul.io/docs/agent/http/query.html) endpoint documentation, as well as the [Node Meta](https://www.consul.io/docs/agent/options.html#_node_meta) section of the agent configuration. [GH-2654]
 * **Node Identifiers:** Consul agents can now be configured with a unique identifier, or they will generate one at startup that will persist across agent restarts. This identifier is designed to represent a node across all time, even if the name or address of the node changes. Identifiers are currently only exposed in node-related endpoints, but they will be used in future versions of Consul to help manage Consul servers and the Raft quorum in a more robust manner, as the quorum is currently tracked via addresses, which can change. [GH-2661]
-* **Improved Blocking Queries:** Consul's [blocking query](https://www.consul.io/docs/agent/http.html#blocking-queries) implementation was improved to provide a much more fine-grained mechanism for detecting changes. For example, in previous versions of Consul blocking to wait on a change to a specific service would result in a wake up if any service changed. Now, wake ups are scoped to the specific service being watched, if possible. This support has been added to all endpoints that support blocking queries, nothing new is required to take advantage of this feature. [GH-2671]
+* **Improved Blocking Queries:** Consul's [blocking query](https://www.consul.io/api/index.html#blocking-queries) implementation was improved to provide a much more fine-grained mechanism for detecting changes. For example, in previous versions of Consul blocking to wait on a change to a specific service would result in a wake up if any service changed. Now, wake ups are scoped to the specific service being watched, if possible. This support has been added to all endpoints that support blocking queries, nothing new is required to take advantage of this feature. [GH-2671]
 * **GCE auto-discovery:** New `-retry-join-gce` configuration options added to allow bootstrapping by automatically discovering Google Cloud instances with a given tag at startup. [GH-2570]
 
 IMPROVEMENTS:

ui/README.md

@@ -5,7 +5,7 @@ HTTP server that serves this directory, but any common HTTP server
 is capable of serving it.
 
 It uses JavaScript and [Ember](http://emberjs.com) to communicate with
-the [Consul API](https://www.consul.io/docs/agent/http.html). The basic
+the [Consul API](https://www.consul.io/api/index.html). The basic
 features it provides are:
 
 - Service view. A list of your registered services, their

website/source/docs/agent/basics.html.markdown

@@ -69,7 +69,7 @@ There are several important messages that [`consul agent`](/docs/commands/agent.
   to localhost. If you change this address or port, you'll have to specify a `-http-addr`
   whenever you run commands such as [`consul members`](/docs/commands/members.html) to
   indicate how to reach the agent. Other applications can also use the HTTP address and port
-  [to control Consul](/docs/agent/http.html).
+  [to control Consul](/api/index.html).
 
 * **Cluster Addr**: This is the address and set of ports used for communication between
   Consul agents in a cluster. Not all Consul agents in a cluster have to

website/source/docs/agent/checks.html.markdown

@@ -187,7 +187,7 @@ To configure a check, either provide it as a `-config-file` option to the
 agent or place it inside the `-config-dir` of the agent. The file must
 end in the ".json" extension to be loaded by Consul. Check definitions can
 also be updated by sending a `SIGHUP` to the agent. Alternatively, the
-check can be registered dynamically using the [HTTP API](/docs/agent/http.html).
+check can be registered dynamically using the [HTTP API](/api/index.html).
 
 ## Check Scripts
 

website/source/docs/agent/options.html.markdown

@@ -1026,7 +1026,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
   <br>
   Starting in Consul 0.7 and later, node addresses in responses to HTTP requests will also prefer a
   node's configured <a href="#_advertise-wan">WAN address</a> when querying for a node in a remote
-  datacenter. An [`X-Consul-Translate-Addresses`](/docs/agent/http.html#translate_header) header
+  datacenter. An [`X-Consul-Translate-Addresses`](/api/index.html#translate_header) header
   will be present on all responses when translation is enabled to help clients know that the addresses
   may be translated. The `TaggedAddresses` field in responses also have a `lan` address for clients that
   need knowledge of that address, regardless of translation.

website/source/docs/agent/rpc.html.markdown

@@ -9,7 +9,7 @@ description: |-
 # RPC Protocol
 
 ~> The RPC Protocol is deprecated and support will be removed in Consul
-   0.8.0. Please use the [HTTP API](/docs/agent/http.html), which has
+   0.8.0. Please use the [HTTP API](/api/index.html), which has
    support for all features of the RPC Protocol.
 
 The Consul agent provides a complete RPC mechanism that can
@@ -19,7 +19,7 @@ used by other applications to easily leverage the power
 of Consul without directly embedding.
 
 It is important to note that the RPC protocol does not support
-all the same operations as the [HTTP API](/docs/agent/http.html).
+all the same operations as the [HTTP API](/api/index.html).
 
 ## Implementation Details
 

website/source/docs/agent/services.html.markdown

@@ -103,7 +103,7 @@ the agent or place it inside the `-config-dir` of the agent. The file
 must end in the `.json` extension to be loaded by Consul. Check
 definitions can be updated by sending a `SIGHUP` to the agent.
 Alternatively, the service can be registered dynamically using the [HTTP
-API](/docs/agent/http.html).
+API](/api/index.html).
 
 ## Multiple Service Definitions
 

website/source/docs/agent/watches.html.markdown

@@ -13,7 +13,7 @@ checks) which is monitored for updates. When an update is detected, an external
 is invoked. A handler can be any executable. As an example, you could watch the status
 of health checks and notify an external system when a check is critical.
 
-Watches are implemented using blocking queries in the [HTTP API](/docs/agent/http.html).
+Watches are implemented using blocking queries in the [HTTP API](/api/index.html).
 Agents automatically make the proper API calls to watch for changes
 and inform a handler when the data view has updated.
 
@@ -43,7 +43,7 @@ match the format of the API.
 
 Additionally, the `CONSUL_INDEX` environment variable will be set.
 This maps to the `X-Consul-Index` value in responses from the
-[HTTP API](/docs/agent/http.html).
+[HTTP API](/api/index.html).
 
 ## Global Parameters
 

website/source/docs/guides/performance.html.markdown

@@ -85,7 +85,7 @@ reasonable, non-zero [DNS TTL values](/docs/guides/dns-cache.html#ttl) if your c
 respect them.
 
 * In other applications that perform high volumes of reads against Consul, consider using the
-[stale consistency mode](/docs/agent/http.html#consistency) available to allow reads to scale
+[stale consistency mode](/api/index.html#consistency) available to allow reads to scale
 across all the servers and not just be forwarded to the leader.
 
 ## Memory Requirements

website/source/docs/internals/acl.html.markdown

@@ -34,7 +34,7 @@ The type is either "client" (meaning the token cannot modify ACL rules) or "mana
 The token ID is passed along with each RPC request to the servers. Agents
 can be configured with an [`acl_token`](/docs/agent/options.html#acl_token) property
 to provide a default token, but the token can also be specified by a client on a
-[per-request basis](/docs/agent/http.html). ACLs were added in Consul 0.4, meaning
+[per-request basis](/api/index.html). ACLs were added in Consul 0.4, meaning
 prior versions do not provide a token. This is handled by the special "anonymous"
 token. If no token is provided, the rules associated with the anonymous token are
 automatically applied: this allows policy to be enforced on legacy clients.
@@ -400,7 +400,7 @@ methods of configuring ACL tokens to use for registration events:
    of multiple tokens on the same agent. Examples of what this looks like are
    available for both [services](/docs/agent/services.html) and
    [checks](/docs/agent/checks.html). Tokens may also be passed to the
-   [HTTP API](/docs/agent/http.html) for operations that require them.
+   [HTTP API](/api/index.html) for operations that require them.
 
 <a name="discovery_acls"></a>
 #### Restricting service discovery with ACLs

website/source/docs/internals/consensus.html.markdown

@@ -170,7 +170,7 @@ The three read modes are:
   a cluster that is unavailable will still be able to respond.
 
 For more documentation about using these various modes, see the
-[HTTP API](/docs/agent/http.html).
+[HTTP API](/api/index.html).
 
 ## <a name="deployment_table"></a>Deployment Table
 

website/source/docs/upgrade-specific.html.markdown

@@ -173,7 +173,7 @@ and the agents need to be running version 0.7 or later in order to use this
 feature.
 
 These translated addresses could break HTTP endpoint consumers that are
-expecting local addresses, so a new [`X-Consul-Translate-Addresses`](/docs/agent/http.html#translate_header)
+expecting local addresses, so a new [`X-Consul-Translate-Addresses`](/api/index.html#translate_header)
 header was added to allow clients to detect if translation is enabled for HTTP
 responses. A "lan" tag was added to `TaggedAddresses` for clients that need
 the local address regardless of translation.

website/source/intro/getting-started/agent.html.markdown

@@ -97,7 +97,7 @@ The output of the [`members`](/docs/commands/members.html) command is based on
 the [gossip protocol](/docs/internals/gossip.html) and is eventually consistent.
 That is, at any point in time, the view of the world as seen by your local
 agent may not exactly match the state on the servers. For a strongly consistent
-view of the world, use the [HTTP API](/docs/agent/http.html) as it forwards the
+view of the world, use the [HTTP API](/api/index.html) as it forwards the
 request to the Consul servers:
 
 ```text

website/source/intro/getting-started/services.html.markdown

@@ -19,7 +19,7 @@ our first service and query that service.
 
 A service can be registered either by providing a
 [service definition](/docs/agent/services.html) or by making the appropriate
-calls to the [HTTP API](/docs/agent/http.html).
+calls to the [HTTP API](/api/index.html).
 
 A service definition is the most common way to register services, so we'll
 use that approach for this step. We'll be building on the agent configuration