<p><strong>EDIT</strong>: As mentioned in <a href="https://stackoverflow.com/users/213269/jonas">Jonas'</a> response Kubernetes REST API can be actually considered as declarative and not imperative.</p>
<p>Kubernetes is well known for its declarative model.
Controller are watching objects in ETCD which contains the desired state (declarative). It compares it to the current state and generates imperative commands to the <a href="https://v1-18.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/" rel="nofollow noreferrer">imperative Kubernetes API</a>.</p>
<p><strong>Which reasons leads Kubernetes project to not expose a declarative HTTP API?</strong></p>
<p>Thus let the controller/operator do the reconciliation.</p>
<p>An example of declarative REST API, I found is <a href="https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/userguide/about-as3.html" rel="nofollow noreferrer">F5 AS3</a>. And I guess their <a href="https://clouddocs.f5.com/containers/latest/userguide/kubernetes/" rel="nofollow noreferrer">Kubernetes operator</a> built on top of this declarative API is quite straightforward.</p>

scoulomb
<p>The Kubernetes API can be used both <em>declaratively</em> and also <em>imperatively</em>. For quick development an imperative workflow might work better whereas for traceability and production workload a declarative workflow is recommended.</p>
<h2>Declarative HTTP example using curl</h2>
<p>This requires to run <code>kubectl proxy</code> first.</p>
<pre><code>curl -X POST -H 'Content-Type: application/yaml' --data '
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-example
spec:
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80
' http://127.0.0.1:8001/apis/apps/v1/namespaces/default/deployments
</code></pre>
<p>The Kubernetes API is <strong>declarative</strong> in the sense that you always specify <strong>what</strong> you want, e.g. <code>replicas: 2</code> instead of e.g. <code>create 2 replicas</code> that would be the case in an <em>imperative</em> API. The controllers then &quot;drives&quot; the state to &quot;what&quot; you specified in a reconciliation loop.</p>
<p>See:</p>
<ul>
<li><a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/" rel="nofollow noreferrer">Declarative Management of Kubernetes Objects Using Configuration Files</a></li>
<li><a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/" rel="nofollow noreferrer">Imperative Management of Kubernetes Objects Using Configuration Files</a></li>
<li><a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/" rel="nofollow noreferrer">Managing Kubernetes Objects Using Imperative Commands</a></li>
</ul>
<p>From your link:</p>
<blockquote>
<p>The Application Services 3 Extension uses a declarative model, meaning you send a declaration file using a single Rest API call.</p>
</blockquote>
<p>the Kubernetes API works exactly the same when you apply yaml-manifest files using e.g. <code>kubectl apply -f deployment.yaml</code></p>
