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.
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.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.