summaryrefslogtreecommitdiff
path: root/extending-api.md
diff options
context:
space:
mode:
authorDaniel Smith <dbsmith@google.com>2015-09-24 14:00:27 -0700
committerDaniel Smith <dbsmith@google.com>2015-10-07 15:59:17 -0700
commit10a5a94e2db162bc55f7924fd02ff0bb50f6e2a9 (patch)
treef05b9da347f60034964a212e6dc3c81a092f4d09 /extending-api.md
parent0a4bbec2f64e1a6d8eac9790f7ec9ac527942455 (diff)
Propose combining domain name & group
Also remove group from versions.
Diffstat (limited to 'extending-api.md')
-rw-r--r--extending-api.md31
1 files changed, 15 insertions, 16 deletions
diff --git a/extending-api.md b/extending-api.md
index 628b5a16..beb3d7ac 100644
--- a/extending-api.md
+++ b/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"