我目前正在计划一个新项目，其中涉及一些概念验证原型，以便在真正的应用程序从中发展之前进行测试。该应用程序将主要是一个 iOS 应用程序，它通过 WebService 与远程服务器上的数据库通信，所以这里的东西非常基本。
由于配置 SQL 数据库和编写服务器应用程序（RESTful API）总是需要很长时间，我开始阅读 NoSQL 数据库的可能性以及它们与远程服务器通信/同步的预构建可能性。就我对这些事情的理解而言，这显然会减少服务器部分所需的工作。
现在我开始阅读 MongoDB 以及 Eve (Python)，它扩展了 MongoDB 提供的 HTTP REST API。由于他们的 RESTful API 提供了测试原型所需的一切，我开始问自己，如果我可以从 Eve 的 API 中获得所需的一切，我为什么还要编写自己的 REST API？
使用 Eve 和 MongoDB 的缺点是什么？围绕我的 MongoDB 实例编写自己的 RESTful API 有什么好处？！
Generally, using a prepackaged library will offer benefits early on in a development cycle where you can make rapid progress by not concentrating on the details and muck that can make building a proof of concept application challenging and time consuming.
If you're just building a PoC, then often it doesn't matter what the specifics are of the construction, unless you also need to validate architectural choices. For example, it may be that it's easy to wire up a simple document model with your iOS application, but adding a layer of security on the existing framework may be difficult (I'm saying in general). Or, that by not giving enough attention to the data model, that it later becomes difficult to model the database in a relational database, or that even when staying with the same technology that was used in the PoC, that it won't scale well under load).
By building or extending your own Restful API, you'll have complete control over the entire experience. Many web platforms today make building a restful API quite natural so that the developer can concentrate on the application logic, rather than the plumbing of the architecture. So, you may not need to take on a complete end-to-end framework solution.
Frameworks are often opinionated, often to not any official specification. Once you've moved your code beyond a PoC, you'll want to decide where the risks to a production system are. How many moving parts and widgets are there? What if something goes wrong? Will you be able to understand the interactions? Is support available for the platform? Are the libraries actively maintained and are the issues on their support list long, solvable, etc.?
The challenge of using a document oriented database like MongoDb or CouchDb will be technology transfer if you decide on an alternate database platform later. If you need to adjust, consider how intertwined your business logic and database code is with the various frameworks you've used. It's the same problem if you start RDBMS, and try switching to a Document database. Converting a data model between the two can be very complex regardless of the starting point.
For a PoC you're going to throw away, use what gets things done quickly. If it's more, then you'll need to consider how it fits.
Eve has a small issues list, is updated frequently, and has good documentation. The ultimate decision is up to you.
[免责声明：我是项目作者。]
Eve 的一个明显优势是您可以获得许多开箱即用的功能，我相信这使其成为快速原型设计和 PoC 的理想选择。您可以快速启动并运行，只需更新即可在一分钟内更改您的 API 架构/行为settings.py（如果您在调试模式下运行应用程序，它将在每次保存时重新启动）。您甚至不必创建数据库，因为如果它丢失，它将为您创建。
实际上，我们有一个 Heroku 实例可以做到这一点，我们通过使用免费的 MongoHQ 实例（或 MongoLab，目前不确定）添加新的端点和文档字段作为一次性数据存储（只需清理db 根据需要，但大多数时候我们甚至不需要这样做，这要归功于 mongo 的无模式设计。）
不用说，如果您要在生产中使用它，请不要在调试模式下运行您的应用程序或让它为您创建数据库；-)
PS：为了记录，最初构建 Eve 的全部原因是为我们的 iOS/Android 应用程序提供 Web 服务。