In this section, we will show you how to manage resources through the RESTful API. Generally, the command line pattern of curl will cover the following ideas:

• The operation: curl without an indicating operation will fire GET by default. To specify your operation, add one with the X flag.
• The body data: Like creating a Kubernetes resource through kubectl, we apply resource configuration with the d flag. The value with symbol @ can attach a file. Additionally, the h flag helps to add request headers; here we need to add content type in the JSON format.
• The URL: There are various paths after the endpoint, based on different functions.

Let's create a deployment using the following JSON configuration file:

$ cat nginx-deployment.json
{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "my-nginx"
  },
  "spec": {
    "replicas": 2,
       "selector": {
      "matchLabels": {
        "app": "nginx"
      }
    },
    "template": {
      "metadata": {
        "labels": {
          "app": "nginx"
        }
      },
      "spec": {
        "containers": [
          {
            "image": "nginx",
            "name": "my-nginx"
          }
        ]
      }
    }
  }
}

We can get every function in the API reference page (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/). It is similar to searching for the configuration of a resource while writing up a configuration file. To submit an API request, you should know what kind of resource to work on, and what operation to perform on it. Perform the following procedures to find the corresponding information on the reference webpage:

1. Choose an resource.
2. Choose an operation, for example, read or write.
3. Choose the details of the operation, for example, Create or Delete.
4. The information will show in the middle panel of the webpage. An optional step is to switch kubectl to curl on the top right of the console. More details such as command flags will show on the right panel.

To check the information for creating a Deployment, your web console may look as it does in this screenshot:

Based on the reference page, we can combine a specified curl command and fire a request now:

$ curl -X POST -H "Content-type: application/json" -d @nginx-deployment.json http://localhost:8001/apis/apps/v1/namespaces/default/deployments
{
  "kind": "Deployment",
  "apiVersion": "apps/v1",
  "metadata": {
    "name": "my-nginx",
    "namespace": "default",
    "selfLink": "/apis/apps/v1/namespaces/default/deployments/my-nginx",
    "uid": "6eca324e-2cc8-11e8-806a-080027b04dc6",
    "resourceVersion": "209",
    "generation": 1,
    "creationTimestamp": "2018-03-21T05:26:39Z",
    "labels": {
      "app": "nginx"
    }
  },
...

For a successful request, the server returns the status of the resource. Go ahead and check if we can find the new Deployment through the kubectl command:

$ kubectl get deployment
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
my-nginx   2         2         2            2           1m

Of course, it also works while checking it via the RESTful API:

// the operation "-X GET" can be ignored, since
$ curl -X GET http://localhost:8001/apis/apps/v1/namespaces/default/deployments

Next, try to delete this new Deployment, my-nginx, as well. It is a kind of write operation:

$ curl -X DELETE http://localhost:8001/apis/apps/v1/namespaces/default/deployments/my-nginx
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
  },
  "status": "Success",
  "details": {
    "name": "my-nginx",
    "group": "apps",
    "kind": "deployments",
    "uid": "386a3aaa-2d2d-11e8-9843-080027b04dc6"
  }
}