docs: fix typo

Signed-off-by: Han Xiao <[email protected]>

docs/cloud-nativeness/k8s.md

@@ -47,7 +47,7 @@ The export function {meth}`~jina.Deployment.to_kubernetes_yaml` and {meth}`~jina
 ```
 ````{admonition} Matching Jina versions
 :class: caution
-If you change the Docker images for {class}`~jina-serve.Executor` and {class}`~jina-serve.Gateway` in your Kubernetes-generated file, ensure that all of them are built with the same Jina-serve version to guarantee compatibility.
+If you change the Docker images for {class}`~jina.Executor` and {class}`~jina.Gateway` in your Kubernetes-generated file, ensure that all of them are built with the same Jina-serve version to guarantee compatibility.
 ````
 
 You can't add basic Kubernetes features like `Secrets`, `ConfigMap` or `Labels` via the Pythonic or YAML interface. This is intentional and doesn't mean that we don't support these features. On the contrary, we let you fully express your Kubernetes configuration by using the Kubernetes API to add your own Kubernetes standard to Jina-serve.
@@ -129,7 +129,7 @@ This can be done in a Pythonic way or in YAML:
 
 ````{tab} Using Python
 
-You can use {meth}`~jina-serve.Flow.config_gateway` to add `replicas` parameter
+You can use {meth}`~jina.Flow.config_gateway` to add `replicas` parameter
 ```python
 from jina import Flow
 
@@ -161,6 +161,6 @@ You can use a custom Docker image for the Gateway deployment by setting the envi
 ## See also
 - {ref}`Step by step deployment of a Jina-serve Flow on Kubernetes <kubernetes>`
 - {ref}`Export a Flow to Kubernetes <kubernetes-export>`
-- {meth}`~jina-serve.Flow.to_kubernetes_yaml`
+- {meth}`~jina.Flow.to_kubernetes_yaml`
 - {ref}`Deploy a standalone Executor on Kubernetes <kubernetes-executor>`
 - [Kubernetes Documentation](https://kubernetes.io/docs/home/)

docs/concepts/client/index.md

@@ -66,7 +66,7 @@ with Flow(port=1234, protocol='grpc') as f:
 The Client has to specify the followings parameters to match the Flow and how it was set up:
 * the `protocol` it needs to use to communicate with the Flow
 * the `host` and the `port` as exposed by the Flow
-* if it needs to use `TLS` encryption (to connect to a {class}`~jina-serve.Flow` that has been {ref}`configured to use TLS <flow-tls>` in combination with gRPC, http, or websocket)
+* if it needs to use `TLS` encryption (to connect to a {class}`~jina.Flow` that has been {ref}`configured to use TLS <flow-tls>` in combination with gRPC, http, or websocket)
 
 
 ````{Hint} Default port
@@ -186,7 +186,7 @@ c.post(
 (client-compress)=
 ## Enable compression
 
-If the communication to the Gateway is via gRPC, you can pass `compression` parameter to  {meth}`~jina-serve.clients.mixin.PostMixin.post` to benefit from [gRPC compression](https://grpc.github.io/grpc/python/grpc.html#compression) methods. 
+If the communication to the Gateway is via gRPC, you can pass `compression` parameter to  {meth}`~jina.clients.mixin.PostMixin.post` to benefit from [gRPC compression](https://grpc.github.io/grpc/python/grpc.html#compression) methods. 
 
 The supported choices are: None, `gzip` and `deflate`.
 
@@ -212,7 +212,7 @@ One can also specify the compression of the internal communication {ref}`as desc
 
 ## Simple profiling of the latency
 
-Before sending any real data, you can test the connectivity and network latency by calling the {meth}`~jina-serve.clients.mixin.ProfileMixin.profiling` method:
+Before sending any real data, you can test the connectivity and network latency by calling the {meth}`~jina.clients.mixin.ProfileMixin.profiling` method:
 
 ```python
 from jina import Client

docs/concepts/client/send-receive-data.md

@@ -98,7 +98,7 @@ Hence, `deployment.post()` and `flow.post()` are not recommended outside of test
 (request-size-client)=
 ## Send data in batches
 
-Especially during indexing, a Client can send up to thousands or millions of Documents to a {class}`~jina-serve.Flow`.
+Especially during indexing, a Client can send up to thousands or millions of Documents to a {class}`~jina.Flow`.
 Those Documents are internally batched into a `Request`, providing a smaller memory footprint and faster response times
 thanks
 to {ref}`callback functions <callback-functions>`.
@@ -117,8 +117,8 @@ with Deployment() as dep:
 
 ## Send data asynchronously
 
-There is an async version of the Python Client which works with {meth}`~jina-serve.clients.mixin.PostMixin.post` and
-{meth}`~jina-serve.clients.mixin.MutateMixin.mutate`.
+There is an async version of the Python Client which works with {meth}`~jina.clients.mixin.PostMixin.post` and
+{meth}`~jina.clients.mixin.MutateMixin.mutate`.
 
 While the standard `Client` is also asynchronous under the hood, its async version exposes this fact to the outside
 world,
@@ -165,8 +165,8 @@ class DummyExecutor(Executor):
 
 ## Send data to specific Executors
 
-Usually a {class}`~jina-serve.Flow` will send each request to all {class}`~jina-serve.Executor`s with matching endpoints as
-configured. But the {class}`~jina-serve.Client` also allows you to only target specific Executors in a Flow using
+Usually a {class}`~jina.Flow` will send each request to all {class}`~jina.Executor`s with matching endpoints as
+configured. But the {class}`~jina.Client` also allows you to only target specific Executors in a Flow using
 the `target_executor` keyword. The request will then only be processed by the Executors which match the provided
 target_executor regex. Its usage is shown in the listing below.
 
@@ -209,7 +209,7 @@ Executor.
 
 The Flow with **gRPC** protocol implements the unary and the streaming RPC lifecycle for communicating with the clients.
 When sending more than one request using the batching or the iterator mechanism, the RPC lifecycle for the
-{meth}`~jina-serve.clients.mixin.PostMixin.post` method can be controlled using the `stream` boolean method argument. By
+{meth}`~jina.clients.mixin.PostMixin.post` method can be controlled using the `stream` boolean method argument. By
 default the stream option is set to `True` which uses the streaming RPC to send the data to the Flow. If the stream
 option is set to `False`, the unary RPC is used to send the data to the Flow.
 Both RPC lifecycles are implemented to provide the flexibility for the clients.
@@ -247,7 +247,7 @@ used to overwrite the default options. The default **gRPC** options are:
 # allow grpc pings from client without data every 4 seconds
 ```
 
-If the `max_attempts` is greater than 1 on the {meth}`~jina-serve.clients.mixin.PostMixin.post` method,
+If the `max_attempts` is greater than 1 on the {meth}`~jina.clients.mixin.PostMixin.post` method,
 the `grpc.service_config` option will not be applied since the retry
 options will be configured internally.
 
@@ -261,9 +261,9 @@ Refer to the {ref}`Configure Executor gRPC options <executor-grpc-server-options
 
 ## Returns
 
-{meth}`~jina-serve.clients.mixin.PostMixin.post` returns a `DocList` containing all Documents flattened over all
+{meth}`~jina.clients.mixin.PostMixin.post` returns a `DocList` containing all Documents flattened over all
 Requests. When setting `return_responses=True`, this behavior is changed to returning a list of
-{class}`~jina-serve.types.request.data.Response` objects.
+{class}`~jina.types.request.data.Response` objects.
 
 If a callback function is provided, `client.post()` will return none.
 
@@ -331,7 +331,7 @@ None
 
 ### Return type
 
-{meth}`~jina-serve.clients.mixin.PostMixin.post` returns the Documents as the server sends them back. In order for the client to 
+{meth}`~jina.clients.mixin.PostMixin.post` returns the Documents as the server sends them back. In order for the client to 
 return the user's expected document type, the `return_type` argument is required.
 
 The `return_type` can be a parametrized `DocList` or a single `BaseDoc` type. If the return type parameter is a `BaseDoc` type,
@@ -355,7 +355,7 @@ requests may not be the same order as the Client sending them. Hence, the respon
 the sending order.
 
 To force the order of the results to be deterministic and the same as when they are sent, passing `results_in_order`
-parameter to {meth}`~jina-serve.clients.mixin.PostMixin.post`.
+parameter to {meth}`~jina.clients.mixin.PostMixin.post`.
 
 ```python
 import random

docs/concepts/orchestration/add-executors.md

@@ -58,7 +58,7 @@ f = Flow(extra_search_paths=['../executor']).add(uses='config1.yml').add(uses='c
 
 (flow-configure-executors)=
 ## Configure Executors
-You can set and override {class}`~jina-serve.Executor` configuration when adding them to an Orchestration.
+You can set and override {class}`~jina.Executor` configuration when adding them to an Orchestration.
 
 This example shows how to start a Flow with an Executor using the Python API:
 

docs/concepts/orchestration/deployment.md

@@ -166,14 +166,14 @@ dep.save_config('deployment.yml')
 
 ## Start and stop
 
-When a {class}`~jina-serve.Deployment` starts, all the replicated Executors will start as well, making it possible to {ref}`reach the service through its API <third-party-client>`.
+When a {class}`~jina.Deployment` starts, all the replicated Executors will start as well, making it possible to {ref}`reach the service through its API <third-party-client>`.
 
 There are three ways to start a Deployment: In Python, from a YAML file, or from the terminal.
 
 - Generally in Python: use Deployment as a context manager.
 - As an entrypoint from terminal: use `Jina CLI <cli>` and a Deployment YAML file.
 - As an entrypoint from Python code: use Deployment as a context manager inside `if __name__ == '__main__'`
-- No context manager, manually call {meth}`~jina-serve.Deployment.start` and {meth}`~jina-serve.Deployment.close`.
+- No context manager, manually call {meth}`~jina.Deployment.start` and {meth}`~jina.Deployment.close`.
 
 ````{tab} General in Python
 ```python