问题标签 [google-cloud-endpoints-v2]

以前，我使用它在 build.gradle 文件中的 IPv4 地址上访问 App Engine：

但升级到 Cloud Endpoint 插件后，此选项已删除。欢迎任何帮助。

如何在 python 2.7 中为 Google Cloud Endpoints Frameworks 将 messages.Message 解码为 JSON？特别是当我们有一些嵌套消息时。端点版本：

google-endpoints==2.4.5和google-endpoints-api-management==1.3.0

我尝试将方法“to_json”添加到消息定义中，但出现“ MessageDefinitionError：只能使用消息定义中的字段。 ”异常。

它看起来像一个基本的操作，但它并不那么容易。Python SDK 这部分需要很大的改进。

回到 Android Studio 2.0，您只需添加一个 Cloud Endpoints 1.0 后端模块，它就会为您生成一个使用 Objectify 的示例项目。这很方便。

但是，Android Studio 3.0 不再具有此功能，Cloud Endpoints 2.0 要求您使用 IntelliJ Ultimate 版本生成App Engine 标准环境项目。然而...... IntelliJ Ultimate 版售价 500 美元，而且似乎没有创建带有 Objectify 的示例项目......叹息......

所以我的问题是，创建使用 Objectify 的示例 Cloud Endpoints 项目的最佳方法是什么？因为到目前为止，除非您想花 500 美元购买 IntelliJ Ultimate 版本，否则似乎没有明确的方法可以阅读文档。

我错过了什么吗？

故事： 我在 android studio 中使用 google cloud endpoints 1.0 没有任何问题。然而，谷歌决定将云工具插件从 Android Studio 迁移到 IntelliJ idea，所以我按照https://cloud.google.com/endpoints/docs/frameworks/java/migrating将我的项目迁移到云端点 2.0

问题： 我按照这个进行本地部署和调试。我可以通过运行 AppengineDebug 来调试我的代码，但是

返回空值。

sample.json 文件位于src/main/resources

appengine-web.xml

当我从 gradle 运行appengineRun任务时，getResourceAsStream 工作成功，但我无法通过运行 appengineRun 任务来调试代码

问题
1- 如何通过运行 appengineRun 任务来调试代码？

2-运行 AppengineDebug 时如何读取资源文件夹

如果 Openapi YAML 配置从多个文件引用并将文件存储在文件夹结构中，是否可以将其部署到 Google Endpoints？

例如：

假设 openapi.yaml 对 service1.yaml 和 service2.yaml 中的一个或多个定义有 $ref。

请注意，我有大量的文件夹和 YAML，以上只是我想要实现的一个示例。

如何使用服务管理将此结构按原样部署到 Google Endpoints？

在我们的 Cloud Endpoint 从 v1 迁移到 V2 的过程中，我们注意到客户端生成的 Service Definition 类的名称没有使用 @Api 注解定义中定义的 canonicalName

例如

生成 customer-v1-java.zip 并使用名称 Customer 而不是 CustomerAPI 生成服务定义类。

我们应用的 build.gradle 如下所示

而servers/api中的build.gradle如下

为什么不尊重 canonicalName 的任何想法？

我们已经在我们的应用程序中成功使用 Endpoints V1 几年了。现在，当尝试迁移到 Endpoints V2 时，它突然因为找不到 EndpointsServlet 而突然刹车，并且总是返回 404。

• 我可以使用https://apis-explorer.appspot.com/apis-explorer/浏览 api
• 我可以看到请求到达后端并且我正在使用一个过滤器
• 但它永远不会找到/到达 EndpointsServlet 或任何 Endpoints
• 奇怪的是它在 localhost devserver 中工作？

这仍然是一个已知问题（对于某些应用程序）还是我该如何解决这个问题？

404 响应如下所示：

我对 REST 和谷歌云端点很陌生。我遵循了 App Engine 上的 Endpoints Frameworks 入门教程，并成功执行了教程中所述的 API 查询：

curl --header "Content-Type: application/json" --request POST --data '{"message":"hello world"}' http://localhost:8080/_ah/api/echo/v1/echo

但是我没有管理它找到要在浏览器中使用的相应URI查询语句。

我试过了

• http://localhost:8080/_ah/api/echo/v1/echo ?{"message":"hello world"}

• http://localhost:8080/_ah/api/echo/v1/echo?=message= “你好世界”

并且很多组合都没有成功，导致没有收到任何响应。

对应于上述 cURL 请求的 URI 语句是什么样的？

先感谢您。

顺便说一句：这是 API 方法“echo”的端点实现：

我是 google-cloud-endpoints 和相关产品“google-cloud-app-engine”的初学者。

我创建了一个简单的 google app angine 项目/应用程序，并使用 google 云平台的控制台创建了一个 API-Key。

在我的应用引擎的端点 API 定义中，我添加了注释“ apiKeyRequired = AnnotationBoolean.TRUE ”，如 通过向应用引擎应用程序添加 API 密钥来添加 API 限制中所述

并且我的使用生成的端点客户端 API 的客户端应用程序也相应地更新，以便为所有 API 请求发送生成的 API 密钥。

由于我想在将后端部署到云端之前在我的开发机器上本地测试“API-Key”机制（使用本地应用程序引擎环境），我想知道是否可以测试“API -Key” - 本地限制。我的意思是，本地执行的应用引擎后端应用程序必须知道创建的 API 密钥。也许我必须向我的应用引擎后端应用程序的 POM.xml 文件提供一个属性...我不知道，谷歌应用引擎 SDK 是否支持在“端点框架”的上下文中进行本地测试的 API 密钥v2”实际上。newley推出的API管理平台（API-Gateway）可能无法在本地“模拟”......？！

到目前为止，感谢您的努力！

几年来，我有一个基于 Python 的 Google App Engine 应用程序使用 Cloud Endpoints 1.0 运行良好，没有发生任何事故。我在迁移到 Cloud Endpoints 2.0 时遇到了麻烦。

目前，在清除了其他类似问题中描述的许多先前障碍之后，我处于以下状态：

• 我有一个名为gce1的服务版本，它使用 Endpoints 1.0 并设置为接收 100% 流量的默认服务。我可以将 API 客户端和 APIs Explorer 指向gce1-dot-myservice.appspot.com默认值myservice.appspot.com，一切正常。我可以在日志中验证这里发生的任何事情都在使用 GCE 1.0。
• 我有一个名为gce2的服务的第二个版本，默认情况下它不接收任何流量，但是如果我将 API 客户端或 API 资源管理器指向gce2-dot-myservice.appspot.com它就可以正常工作，并且我可以在日志中验证这里发生的任何事情是使用 GCE 2.0。

太好了，对吧？因此，似乎我需要做的就是将所有流量迁移到gce2，然后我就完成了。

但是......当我这样做时，一切都会中断！默认为我现有的客户端myservice.appspot.com提供405 POST Method Not Allowed响应，如果我查看 APIs Explorer，突然间它现在显示了一堆我认为是多年前的过时方法，并且不再在我当前的 API 中使用。我不知道这些是从哪里来的（它们在我的代码中不存在，并且已经好几年没有了），而且无论我做什么，我都无法获得为 GCE 2.0 API 提供服务的默认服务。

最大的问题是我有成千上万的用户都指向默认的 API URL，所以让他们开始指向并不那么容易gce2-dot-myservice，而且，我不能这样做没有任何意义t 使新默认值成为新默认值。几个月来，我一直致力于迁移到 GCE 2.0，离开 GCE 1.0 的截止日期越来越近，而 Google 支持自去年年底以来就没有对此主题作出回应。

我还应该提到我已经尝试过：

• 使用 GCE2.0 代码直接将新服务推送到默认值
• 推送一个完全没有 API 的新服务（可能会清除缓存或其他东西）
• 使用各种不同的版本名称推送服务

这些都没有奏效，尽管我没有做过任何允许长时间延迟的操作，因为我正在与真实用户一起进行实时服务。