diff options
| author | Daniel Smith <dbsmith@google.com> | 2015-09-24 14:00:27 -0700 |
|---|---|---|
| committer | Daniel Smith <dbsmith@google.com> | 2015-10-07 15:59:17 -0700 |
| commit | 10a5a94e2db162bc55f7924fd02ff0bb50f6e2a9 (patch) | |
| tree | f05b9da347f60034964a212e6dc3c81a092f4d09 /extending-api.md | |
| parent | 0a4bbec2f64e1a6d8eac9790f7ec9ac527942455 (diff) | |
Propose combining domain name & group
Also remove group from versions.
Diffstat (limited to 'extending-api.md')
| -rw-r--r-- | extending-api.md | 31 |
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" |
