}

	result2 := msgUnPath("/skydns/local/cluster/staging/service")
	if result2 != "service.staging.cluster.local.skydns" {
		t.Errorf("Failure to get domain from etcd key (without trailing '/'), expect: 'service.staging.cluster.local.' actually get: '%s'", result2)
	}

	result3 := msgUnPath("/singleleveldomain/")

app = FastAPI(
    servers=[
        {"url": "/", "description": "Default, relative server"},
        {
            "url": "http://staging.localhost.tiangolo.com:8000",
            "description": "Staging but actually localhost still",
        },
        {"url": "https://prod.example.com"},
    ]
)


@app.get("/foo")
def foo():
    return {"message": "Hello World"}


client = TestClient(app)

The webhooks that you define will end up in the **OpenAPI** schema and the automatic **docs UI**.

/// info

The `app.webhooks` object is actually just an `APIRouter`, the same type you would use when structuring your app with multiple files.

///

```

////

The last `CommonQueryParams`, in:

```Python
... Depends(CommonQueryParams)
```

...is what **FastAPI** will actually use to know what is the dependency.

It is from this one that FastAPI will extract the declared parameters and that is what FastAPI will actually call.

---

In this case, the first `CommonQueryParams`, in:

//// tab | Python 3.9+

```Python

### `scope` { #scope }

The spec also says that the client can send another form field "`scope`".

The form field name is `scope` (in singular), but it is actually a long string with "scopes" separated by spaces.

Each "scope" is just a string (without spaces).

They are normally used to declare specific security permissions, for example:

## Return Type and Data Filtering { #return-type-and-data-filtering }

Let's continue from the previous example. We wanted to **annotate the function with one type**, but we wanted to be able to return from the function something that actually includes **more data**.

We want FastAPI to keep **filtering** the data using the response model. So that even though the function returns more data, the response will only include the fields declared in the response model.

{* ../../docs_src/body_fields/tutorial001_an_py310.py hl[11:14] *}

`Field` works the same way as `Query`, `Path` and `Body`, it has all the same parameters, etc.

/// note | Technical Details

Actually, `Query`, `Path` and others you'll see next create objects of subclasses of a common `Param` class, which is itself a subclass of Pydantic's `FieldInfo` class.

And Pydantic's `Field` returns an instance of `FieldInfo` as well.

Import `SQLModel` and create a database model:

{* ../../docs_src/sql_databases/tutorial001_an_py310.py ln[1:11] hl[7:11] *}

The `Hero` class is very similar to a Pydantic model (in fact, underneath, it actually *is a Pydantic model*).

There are a few differences:

   *
   * <p>Note that, in cases where {@code sizeIfKnown} returns zero, it is <i>possible</i> that bytes
   * are actually available for reading. (For example, some special files may return a size of 0
   * despite actually having content when read.) This means that a source may return {@code true}
   * from {@code isEmpty()} despite having readable content.
   *

* Retrieve the stored data.
* Put that data in a Pydantic model.
* Generate a `dict` without default values from the input model (using `exclude_unset`).
    * This way you can update only the values actually set by the user, instead of overriding values already stored with default values in your model.
* Create a copy of the stored model, updating its attributes with the received partial updates (using the `update` parameter).