Merge pull request #358 from pmorie/api-broken-links

Fix numerous broken links in API conventions doc

1 files changed, 14 insertions, 15 deletions

diff --git a/contributors/devel/api-conventions.md b/contributors/devel/api-conventions.md
index adca3a31..0c57f7dd 100644
--- a/contributors/devel/api-conventions.md
+++ b/contributors/devel/api-conventions.md
@@ -5,8 +5,7 @@ Updated: 4/22/2016
 
 *This document is oriented at users who want a deeper understanding of the
 Kubernetes API structure, and developers wanting to extend the Kubernetes API.
-An introduction to using resources with kubectl can be found in [Working with
-resources](../user-guide/working-with-resources.md).*
+An introduction to using resources with kubectl can be found in [the object management overview](https://kubernetes.io/docs/concepts/tools/kubectl/object-management-overview/).*
 
 **Table of Contents**
 <!-- BEGIN MUNGE: GENERATED_TOC -->
@@ -53,7 +52,7 @@ resources](../user-guide/working-with-resources.md).*
 
 <!-- END MUNGE: GENERATED_TOC -->
 
-The conventions of the [Kubernetes API](../api.md) (and related APIs in the
+The conventions of the [Kubernetes API](https://kubernetes.io/docs/api/) (and related APIs in the
 ecosystem) are intended to ease client development and ensure that configuration
 mechanisms can be implemented that work across a diverse set of use cases
 consistently.
@@ -114,7 +113,7 @@ the full list. Some objects may be singletons (the current user, the system
 defaults) and may not have lists.
 
    In addition, all lists that return objects with labels should support label
-filtering (see [docs/user-guide/labels.md](../user-guide/labels.md), and most
+filtering (see [the labels documentation](https://kubernetes.io/docs/user-guide/labels/)), and most
 lists should support filtering by fields.
 
    Examples: PodLists, ServiceLists, NodeLists
@@ -150,7 +149,7 @@ is independent of the specific resource schema.
 
    Two additional subresources, `proxy` and `portforward`, provide access to
 cluster resources as described in
-[docs/user-guide/accessing-the-cluster.md](../user-guide/accessing-the-cluster.md).
+[accessing the cluster docs](https://kubernetes.io/docs/user-guide/accessing-the-cluster/).
 
 The standard REST verbs (defined below) MUST return singular JSON objects. Some
 API endpoints may deviate from the strict REST pattern and return resources that
@@ -181,12 +180,12 @@ called "metadata":
 
 * namespace: a namespace is a DNS compatible label that objects are subdivided
 into. The default namespace is 'default'. See
-[docs/user-guide/namespaces.md](../user-guide/namespaces.md) for more.
+[the namespace docs](https://kubernetes.io/docs/user-guide/namespaces/) for more.
 * name: a string that uniquely identifies this object within the current
-namespace (see [docs/user-guide/identifiers.md](../user-guide/identifiers.md)).
+namespace (see [the identifiers docs](https://kubernetes.io/docs/user-guide/identifiers/)).
 This value is used in the path when retrieving an individual object.
 * uid: a unique in time and space value (typically an RFC 4122 generated
-identifier, see [docs/user-guide/identifiers.md](../user-guide/identifiers.md))
+identifier, see [the identifiers docs](https://kubernetes.io/docs/user-guide/identifiers/))
 used to distinguish between objects with the same name that have been deleted
 and recreated
 
@@ -213,10 +212,10 @@ not reachable by name) after the time in this field. Once set, this value may
 not be unset or be set further into the future, although it may be shortened or
 the resource may be deleted prior to this time.
 * labels: a map of string keys and values that can be used to organize and
-categorize objects (see [docs/user-guide/labels.md](../user-guide/labels.md))
+categorize objects (see [the labels docs](https://kubernetes.io/docs/user-guide/labels/))
 * annotations: a map of string keys and values that can be used by external
 tooling to store and retrieve arbitrary metadata about this object (see
-[docs/user-guide/annotations.md](../user-guide/annotations.md))
+[the annotations docs](https://kubernetes.io/docs/user-guide/annotations/)
 
 Labels are intended for organizational purposes by end users (select the pods
 that match this label query). Annotations enable third-party automation and
@@ -359,9 +358,9 @@ the reported status reflects the most recent desired status.
 #### References to related objects
 
 References to loosely coupled sets of objects, such as
-[pods](../user-guide/pods.md) overseen by a
-[replication controller](../user-guide/replication-controller.md), are usually
-best referred to using a [label selector](../user-guide/labels.md). In order to
+[pods](https://kubernetes.io/docs/user-guide/pods/) overseen by a
+[replication controller](https://kubernetes.io/docs/user-guide/replication-controller/), are usually
+best referred to using a [label selector](https://kubernetes.io/docs/user-guide/labels/). In order to
 ensure that GETs of individual objects remain bounded in time and space, these
 sets may be queried via separate API queries, but will not be expanded in the
 referring object's status.
@@ -698,7 +697,7 @@ labels:
 All compatible Kubernetes APIs MUST support "name idempotency" and respond with
 an HTTP status code 409 when a request is made to POST an object that has the
 same name as an existing object in the system. See
-[docs/user-guide/identifiers.md](../user-guide/identifiers.md) for details.
+[the identifiers docs](https://kubernetes.io/docs/user-guide/identifiers/) for details.
 
 Names generated by the system may be requested using `metadata.generateName`.
 GenerateName indicates that the name should be made unique by the server prior
@@ -1296,7 +1295,7 @@ that hard to consistently apply schemas that ensure uniqueness. One just needs
 to ensure that at least one value of some label key in common differs compared
 to all other comparable resources. We could/should provide a verification tool
 to check that. However, development of conventions similar to the examples in
-[Labels](../user-guide/labels.md) make uniqueness straightforward. Furthermore,
+[Labels](https://kubernetes.io/docs/user-guide/labels/) make uniqueness straightforward. Furthermore,
 relatively narrowly used namespaces (e.g., per environment, per application) can
 be used to reduce the set of resources that could potentially cause overlap.