我已经开始为我的Google AppEngine应用程序编写REST API。我读了一篇关于构建REST应用程序的好文章，建议我将我的数据服务封装在REST API之后。考虑到我想准备转移到像Amazon Web Services这样的架构，如果原型获得牵引力，这种封装水平是有道理的。
这个想法是Web页面的请求，应用程序服务器接受HTTP请求。然后，应用程序服务器本身向数据库服务器发出HTTP REST请求，而不是直接通过数据存储区对象。对于Google AppEngine，它实际上是相同的服务器，但很容易更改哪个服务器（或服务器群集）实际响应数据请求。
例如：
注意：这不包括我的任何缓存。
这意味着对于单个客户端HTTP请求，我最终可能会产生4-5个额外的HTTP请求来构建响应。这是一种在Google AppEngine或一般情况下运行良好的架构模式吗？ Google是否以有效的方式处理内部请求（appserver instance-appserver实例）？
答案 0 :(得分：3)
这种模式对AppEngine没有多大意义。
考虑到某些AppEngine资源存在固定限制，例如可能会快速耗尽的URLFetch。此外，可计费的资源（例如CPU时间，传入带宽和传出带宽）的使用速度都比所需的速度快得多。
此外，它极大地限制了AppEngine应用程序的扩展能力。实际上，它是一个负反馈循环。随着外部请求数量的增加，应用程序的负载将非常陡峭。这就是您应该尝试使用AppEngine应用程序实现的对立。
最后，我建议这是任何平台上应用程序的可疑架构，而不仅仅是AppEngine。软件工程师很容易爱上抽象，为了模块化，可移植性，松散耦合等价值而生成层上层 - 这个列表一直在进行。但是，任何因抽象原因而导致性能严重下降的决定都是事实上的反模式。
答案 1 :(得分：1)
首先在架构方面，可以在存储上方构建REST数据访问层，请参阅Microsoft的Azure文档，例如http://msdn.microsoft.com/en-us/library/dd179423.aspx
当你移出app引擎并通过urlfetch进行查询时，自然会遇到某种性能损失。我建议在进行移动之前比较数据存储区与urlfetch的计费。
如果您确实创建了DAL以对远程数据库进行这些REST调用，则没有理由为您的GAE数据存储区实际创建urlfetches。只需编写一个应用程序引擎提供程序，直接使用DataStore API http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/datastore/package-summary.html
进行这些数据库调用