From 72c1340d34ce6a583b19f1ea42548b1cc18c4532 Mon Sep 17 00:00:00 2001
From: Daniel Smith <dbsmith@google.com>
Date: Thu, 24 Sep 2015 14:00:27 -0700
Subject: [PATCH] Propose combining domain name & group

Also remove group from versions.
---
 docs/design/extending-api.md | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/docs/design/extending-api.md b/docs/design/extending-api.md
index 628b5a16a4..beb3d7ac53 100644
--- a/docs/design/extending-api.md
+++ b/docs/design/extending-api.md
@@ -73,11 +73,11 @@ Kubernetes API server to provide the following features:
 The `Kind` for an instance of a third-party object (e.g. CronTab) below is expected to be
 programmatically convertible to the name of the resource using
 the following conversion.  Kinds are expected to be of the form `<CamelCaseKind>`, the
-`APIVersion` for the object is expected to be `<domain-name>/<api-group>/<api-version>`.
+`APIVersion` for the object is expected to be `<api-group>/<api-version>`. To
+prevent collisions, it's expected that you'll use a fulling qualified domain
+name for the API group, e.g. `example.com`.
 
-For example `example.com/stable/v1`
-
-`domain-name` is expected to be a fully qualified domain name.
+For example `stable.example.com/v1`
 
 'CamelCaseKind' is the specific type name.
 
@@ -113,18 +113,17 @@ For example, if a user creates:
 
 ```yaml
 metadata:
-  name: cron-tab.example.com
+  name: cron-tab.stable.example.com
 apiVersion: experimental/v1alpha1
 kind: ThirdPartyResource
 description: "A specification of a Pod to run on a cron style schedule"
 versions:
-  - name: stable/v1
-  - name: experimental/v2
+- name: v1
+- name: v2
 ```
 
-Then the API server will program in two new RESTful resource paths:
-   * `/thirdparty/example.com/stable/v1/namespaces/<namespace>/crontabs/...`
-   * `/thirdparty/example.com/experimental/v2/namespaces/<namespace>/crontabs/...`
+Then the API server will program in the new RESTful resource path:
+   * `/apis/stable.example.com/v1/namespaces/<namespace>/crontabs/...`
 
 
 Now that this schema has been created, a user can `POST`:
@@ -134,19 +133,19 @@ Now that this schema has been created, a user can `POST`:
    "metadata": {
      "name": "my-new-cron-object"
    },
-   "apiVersion": "example.com/stable/v1",
+   "apiVersion": "stable.example.com/v1",
    "kind": "CronTab",
    "cronSpec": "* * * * /5",
    "image":     "my-awesome-chron-image"
 }
 ```
 
-to: `/third-party/example.com/stable/v1/namespaces/default/crontabs/my-new-cron-object`
+to: `/apis/stable.example.com/v1/namespaces/default/crontabs`
 
 and the corresponding data will be stored into etcd by the APIServer, so that when the user issues:
 
 ```
-GET /third-party/example.com/stable/v1/namespaces/default/crontabs/my-new-cron-object`
+GET /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object`
 ```
 
 And when they do that, they will get back the same data, but with additional Kubernetes metadata
@@ -155,21 +154,21 @@ And when they do that, they will get back the same data, but with additional Kub
 Likewise, to list all resources, a user can issue:
 
 ```
-GET /third-party/example.com/stable/v1/namespaces/default/crontabs
+GET /apis/stable.example.com/v1/namespaces/default/crontabs
 ```
 
 and get back:
 
 ```json
 {
-   "apiVersion": "example.com/stable/v1",
+   "apiVersion": "stable.example.com/v1",
    "kind": "CronTabList",
    "items": [
      {
        "metadata": {
          "name": "my-new-cron-object"
        },
-       "apiVersion": "example.com/stable/v1",
+       "apiVersion": "stable.example.com/v1",
        "kind": "CronTab",
        "cronSpec": "* * * * /5",
        "image":     "my-awesome-chron-image"