Skip to content

Commit 2ca81a1

Browse files
author
Tim Bannister
committed
Bump Table API to v1
Table is now GA
1 parent a53db47 commit 2ca81a1

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

content/en/docs/reference/using-api/api-concepts.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -360,20 +360,20 @@ collections that might be of different kinds of object. Avoid depending on
360360
When you run `kubectl get`, the default output format is a simple tabular representation of one or more instances of a particular resource type. In the past, clients were required to reproduce the tabular and describe output implemented in `kubectl` to perform simple lists of objects.
361361
A few limitations of that approach include non-trivial logic when dealing with certain objects. Additionally, types provided by API aggregation or third party resources are not known at compile time. This means that generic implementations had to be in place for types unrecognized by a client.
362362

363-
In order to avoid potential limitations as described above, clients may request the Table representation of objects, delegating specific details of printing to the server. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header containing a value of `application/json;as=Table;g=meta.k8s.io;v=v1beta1` with a `GET` call will request that the server return objects in the Table content type.
363+
In order to avoid potential limitations as described above, clients may request the Table representation of objects, delegating specific details of printing to the server. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header containing a value of `application/json;as=Table;g=meta.k8s.io;v=v1` with a `GET` call will request that the server return objects in the Table content type.
364364

365365
For example, list all of the pods on a cluster in the Table format.
366366

367367
```console
368368
GET /api/v1/pods
369-
Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1
369+
Accept: application/json;as=Table;g=meta.k8s.io;v=v1
370370
---
371371
200 OK
372372
Content-Type: application/json
373373
374374
{
375375
"kind": "Table",
376-
"apiVersion": "meta.k8s.io/v1beta1",
376+
"apiVersion": "meta.k8s.io/v1",
377377
...
378378
"columnDefinitions": [
379379
...
@@ -392,7 +392,7 @@ Content-Type: application/json
392392
393393
{
394394
"kind": "Table",
395-
"apiVersion": "meta.k8s.io/v1beta1",
395+
"apiVersion": "meta.k8s.io/v1",
396396
...
397397
"columnDefinitions": [
398398
{
@@ -412,7 +412,7 @@ Content-Type: application/json
412412
Not all API resource types support a Table response; for example, a {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} might not define field-to-table mappings, and an APIService that [extends the core Kubernetes API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) might not serve Table responses at all. If you are implementing a client that uses the Table information and must work against all resource types, including extensions, you should make requests that specify multiple content types in the `Accept` header. For example:
413413

414414
```console
415-
Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1, application/json
415+
Accept: application/json;as=Table;g=meta.k8s.io;v=v1, application/json
416416
```
417417

418418
## Alternate representations of resources

0 commit comments

Comments
 (0)