Diese Seite enthält Empfehlungen zu Namenskonventionen der Cloudprojekte, die Sie möglicherweise zusätzlich zum Cloudprojekt für Ihr Produktions-Back-End erstellen müssen.
Je nach Zweck der Umgebung und der Phase im API-Lebenszyklus haben Sie folgende Möglichkeiten:
API-Namen oder Cloud Endpoints-Dienstnamen ändern. Weitere Informationen finden Sie unter Endpoints konfigurieren.
Anderes Projekt erstellen
Pfad ändern, über den die API bereitgestellt wird
Es folgen einige allgemeine Muster, die sie verwenden können:
API versionieren: Wenn Sie davon ausgehen, dass Sie künftig rückwärtsinkompatible Änderungen vornehmen müssen, sollten Sie vorausplanen und die Versionsnummer in den Pfad einfügen, über den die API bereitgestellt wird. Beispiel:
my-api.endpoints.my‐project.cloud.goog/v1/echo
Entwicklung/Testinstanzen: Jeder Entwickler erstellt eine eigene Version des Dienstes im jeweils eigenen Projekt. Zum Beispiel verwendet der Entwickler Daniel:
Staging: Bevor Sie Ihre APIs für die Produktion bereitstellen, testen Sie sie in Ihrem Staging-Back-End, das sich in seinem eigenen Projekt befindet. Beispiel:
Private Alphaversion ausführen: Wenn Sie eine neue Version Ihres Dienstes bei einigen, aber nicht allen Kunden testen möchten, ist die einfachste Methode, die Alphaversion in ein eigenes Projekt einzufügen, was das höchste Maß an Isolation von der Produktion bietet. Beispiel:
Alternativ können Sie die Alphaversion auch in dasselbe Projekt einfügen, aber als separaten Dienst konfigurieren. Da es ein separater Dienst ist, können Sie den Zugriff auf die Alpha-Kunden beschränken. Beispiel:
Offene Alphaversion ausführen: Wenn Sie eine Alphaversion veröffentlichen möchten, die für alle Kunden verfügbar ist, können Sie sie in denselben Dienst und dasselbe Projekt wie die vorhandene Version einfügen und den Pfad ändern. Beispiel:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis page offers recommendations for naming conventions of Cloud projects beyond the production backend project.\u003c/p\u003e\n"],["\u003cp\u003eOptions include modifying the API or service name, creating separate projects, or altering the API's serving path based on the API lifecycle stage.\u003c/p\u003e\n"],["\u003cp\u003eCommon patterns include versioning APIs by incorporating version numbers in the path, setting up dedicated projects for development/testing, and using separate projects for staging or alpha releases.\u003c/p\u003e\n"],["\u003cp\u003eFor private alpha releases, either a distinct project or a separate service within the same project can be used for isolation and restricted access.\u003c/p\u003e\n"],["\u003cp\u003eOpen alpha releases can reside in the same project and service as the existing version, but with a unique path.\u003c/p\u003e\n"]]],[],null,["# Planning Your Cloud Projects\n\n[OpenAPI](/endpoints/docs/openapi/planning-cloud-projects \"View this page for the Cloud Endpoints OpenAPI docs\") \\| gRPC\n\n\u003cbr /\u003e\n\nThis page provides recommendations for naming conventions of the Cloud projects\nthat you may need to create in addition to the Cloud project for your production\nbackend.\n\nDepending on the purpose of the environment or the stage in the API lifecycle,\nyou may want to:\n\n- Change the API name or the Cloud Endpoints service name. See [Configuring Endpoints](/endpoints/docs/grpc/configure-endpoints#service_name) for more information.\n- Create a different project.\n- Change the path that the API is served from.\n\nFollowing are some common patterns you may want to use:\n\n- **Versioning the API**: When you think you may need to make backwards-incompatible\n changes in the future, plan ahead and add the version number in the path where\n the API is served from. For example:\n\n - `my-api.endpoints.my‐project.cloud.goog/`**v1**`/echo`\n- **Development/test instances**: Each developer stands up their own version of the\n service, in their own project. For example, Dan the developer uses:\n\n - `my-api.endpoints.`**dan-dev-project**`.cloud.goog/v1/echo`\n- **Staging**: Before you deploy to production, you test your APIs on your\n staging backend, which is in its own project. For example:\n\n - `my-api.endpoints.`**my‐project-staging**`.cloud.goog/v1/echo`\n- **Running a private alpha**: When you want to test a new version of your\n service with some customers, but not all, the easiest approach is to put the\n alpha version in its own project, which provides the highest level of isolation\n from production. For example:\n\n - `my-api.endpoints.`**my‐project-alpha** `.cloud.goog/`**v2alpha**`/echo`\n\n Alternatively, you could put the alpha version in the same project but\n configure it as a separate service. Since it is a separate service, you can\n restrict access to only the alpha customers. For example:\n - **my-api-alpha** `.endpoints.my-project.cloud.goog/`**v2alpha**`/echo`\n- **Running an open alpha**: When you want to release an alpha version that\n is available to all customers, you can put it in the same service and project as\n the existing version, and change the path. For example:\n\n - `my-api.endpoints.my-project.cloud.goog/`**v2alpha**`/echo`"]]
