### Aplicación de nivel superior { #top-level-application }

Primero, crea la aplicación principal de nivel superior de **FastAPI**, y sus *path operations*:

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[3, 6:8] *}

### Sub-aplicación { #sub-application }

Luego, crea tu sub-aplicación, y sus *path operations*.

### Приложение верхнего уровня { #top-level-application }

Сначала создайте основное, верхнего уровня, приложение **FastAPI** и его *операции пути*:

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[3, 6:8] *}

### Подприложение { #sub-application }

Затем создайте подприложение и его *операции пути*.

### Hauptanwendung { #top-level-application }

Erstellen Sie zunächst die Hauptanwendung **FastAPI** und deren *Pfadoperationen*:

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[3, 6:8] *}

### Unteranwendung { #sub-application }

Erstellen Sie dann Ihre Unteranwendung und deren *Pfadoperationen*.

### Top-level application { #top-level-application }

First, create the main, top-level, **FastAPI** application, and its *path operations*:

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[3, 6:8] *}

### Sub-application { #sub-application }

Then, create your sub-application, and its *path operations*.

# Bigger Applications - Multiple Files { #bigger-applications-multiple-files }

If you are building an application or a web API, it's rarely the case that you can put everything in a single file.

**FastAPI** provides a convenience tool to structure your application while keeping all the flexibility.

/// info

If you come from Flask, this would be the equivalent of Flask's Blueprints.

///

## An example file structure { #an-example-file-structure }

### Aplicação de nível superior { #top-level-application }

Primeiro, crie a aplicação principal, de nível superior, **FastAPI**, e suas *operações de rota*:

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[3, 6:8] *}

### Sub-aplicação { #sub-application }

Em seguida, crie sua sub-aplicação e suas *operações de rota*.

class ResponseLevel0(JSONResponse):
    media_type = "application/x-level-0"


class ResponseLevel1(JSONResponse):
    media_type = "application/x-level-1"


class ResponseLevel2(JSONResponse):
    media_type = "application/x-level-2"


class ResponseLevel3(JSONResponse):
    media_type = "application/x-level-3"


class ResponseLevel4(JSONResponse):
    media_type = "application/x-level-4"

Including how to handle lifespan state that can be used in other areas of your code.

///

## Sub Applications { #sub-applications }

                            "description": "Successful Response",
                            "content": {"application/json": {"schema": {}}},
                        },
                        "422": {
                            "description": "Validation Error",
                            "content": {
                                "application/json": {
                                    "schema": {

* do we need a sort of bus for application data
* do we need a dictionary for our applications like Apple does. We could easily hook into this and this is the model we need to follow. Following the model of apple applications the dictionary is what the REST URI should attach to. Not creating custom logic in the resource code.
* how many of our REST services do not map directory to a method in the application interface?

- an example of adding js