Chapter 1. Introduction
1.1. Introduction
1.1.1. Using this Guide
This guide provides step-by-step examples for interacting with the OpenShift and Kubernetes REST APIs. Each section contains a description of the resource or function and a set of applicable actions. Each action features a request breakdown that lists the requests types and expected results, followed by applicable example requests and responses to help guide the user through the process. Example configurations for all resources in this guide can be found in the Resource Examples chapter.
This guide does not include complete listings of all available options for each resource object and should be considered a companion to the comprehensive information found in the REST API Reference Guide.
1.1.1.1. Request Types
GET requests are used to retrieve a resource configuration if that resource is specified by name in the target URL.
For example, a GET request to {$OCP_CLUSTER}/oapi/namespaces/{$PROJECT}/routes/{$ROUTE}
returns that {$ROUTE}
configuration.
Alternatively, GET requests to resource collections return the list objects in that resource collection.
For example, a GET request to {$OCP_CLUSTER}/oapi/namespaces/{$PROJECT}/routes
returns a list of the routes in the {$PROJECT}
namespace.
GET requests do not require a request body.
POST requests are used to create new resources based on the configuration in the request body.
For example, a POST request with a new route configuration in the request body to {$OCP_CLUSTER}/api/namespaces/{$PROJECT}/routes
creates a new route in the {$PROJECT}
namespace.
PUT requests are used to update or modify configurations. A PUT request targets specific resources and requires a complete and modified configuration in the request body.
For example, A PUT request to with a complete route configuration that has had one or more field values updated to {$OCP_CLUSTER}/oapi/namespaces/{$PROJECT}/routes/{$ROUTE}
will replace that {$ROUTE}
configuration.
PATCH requests are used to selectively update or modify field values in a resource configuration. How the change is merged is defined per field.
PATCH requests require JSON formatting and Content-Type: header text/strategic-merge-patch+json.
For example, a PATCH request with the following request body:
{ "spec": { "to": { "weight": 1 } } }
to {$OCP_CLUSTER}/oapi/namespaces/{$PROJECT}/routes/{$ROUTE}
will update the weight
of that route to 1
.
DELETE requests are used to remove resource configurations.
For example, a request to {$OCP_CLUSTER}/oapi/namespaces/{$PROJECT}/routes/{$ROUTE}
removes that route from the {$PROJECT}
namespace.
DELETE requests do not require a request body.
1.1.1.2. Request Examples
Request bodies are typically shown in their simplest form. Detailed object configurations can be found in the Resource Examples chapter. Comprehensive information for each API object can be found in the REST API Reference Guide.
Request and response body snippets are used in some examples. These snippets use ellipses (…
) to delimit the relevant content from the redacted parts of the example configuration.
Request headers use generic {$BEARER_TOKEN}
and {$OCP_CLUSTER}
variables in place of the request authentication bearer token hash, and the OpenShift cluster hostname in the request target url, respectively.
An example OpenShift cluster hostname is:
https://openshift.example.com:8443
Additional variables are included in place of object names. For example, {$PROJECT}
is commonly used in place of a particular namespace.
Request examples in this guide use YAML for readability, and application/yaml is specified in the Accept: and Content-Type: headers to accommodate this. However, PATCH requests require JSON formatting and are documented as such.
1.1.2. API Authentication
Requests to the OpenShift Container Platform API are authenticated using the following methods:
- OAuth Access Tokens
-
Obtained from the OpenShift Container Platform OAuth server using the
<master>/oauth/authorize
and<master>/oauth/token
endpoints. -
Sent as an
Authorization: Bearer…
header -
Sent as an
access_token=…
query parameter for websocket requests prior to OpenShift Container Platform server version 3.6. -
Sent as a websocket subprotocol header in the form
base64url.bearer.authorization.k8s.io.<base64url-encoded-token>
for websocket requests in OpenShift Container Platform server version 3.6 and later.
-
Obtained from the OpenShift Container Platform OAuth server using the
- X.509 Client Certificates
- Requires an HTTPS connection to the API server.
- Verified by the API server against a trusted certificate authority bundle.
- The API server creates and distributes certificates to controllers to authenticate themselves.
Any request with an invalid access token or an invalid certificate is rejected by the authentication layer with a 401 error.
If no access token or certificate is presented, the authentication layer assigns the system:anonymous
virtual user and the system:unauthenticated
virtual group to the request. This allows the authorization layer to determine which requests, if any, an anonymous user is allowed to make.
See the REST API Overview for more information and examples.