我正在计划一个 iOS 应用程序，它需要一个能够有效地提供图像文件并根据它获得的请求执行一些动态操作的服务器后端（例如读取和写入数据存储，例如 Redis）。我最满意，因此更喜欢用 Python 编写后端。
我查看了很多 Python Web 框架/服务器选项，其中包括 Flask、Bottle、static 和 Tornado。共同点似乎是它们要么只支持提供静态文件作为开发时的便利，不鼓励在生产中使用它，要么是高效的静态文件服务器，但并不真正适合动态框架类的东西。这并不是说它们不能充当后端，但乍一看，它们似乎都有些尴尬。
简而言之，我需要一个专门提供 JPEG 而不是生成 HTML 的 Web 框架。我很确定不存在这样的事情，但现在我希望有人可以提出一个解决方案，该解决方案可以在不以它们不适合的方式弯曲使用过的 Python 应用程序的情况下工作。
规格和实际要求
我将提供给客户端的图像存在于文件系统中的浅层目录层次结构中。实际的文件名对客户端是不可见的。服务器将在启动时读取目录层次结构，为每个文件分配一个数字 ID，并将请求路由到控制器方法，然后实际为图像文件提供服务。以下是客户希望在不同情况下访问图像的一些示例：
- 随机（示例 URL 路径
/image/random：） - 随机，每个文件只有一次（
/image/random_unique），当文件用完时会产生一些合适的非 200 HTTP 状态码 - 在任一方向上依次（
/image/0,/image/1等/image/2）
等等。此外，还有一些 URL 端点，用于诸如评级、图像信息和其他元数据，以及一些特定于客户端的信息（客户端将向服务器“注册”，因此也需要一些逻辑）。这些数据很可能存在于 Redis 数据存储中。
总而言之，后端需要擅长提供 image/jpeg 和 application/json（它也会生成）。可扩展性和并发性要求是适度的，至少从一开始就是这样（这不是 App Store 应用程序，用于临时或企业分发）。
我不希望应用程序依赖重定向。也就是说，我不想要一个模型，其中对 URL 的请求将返回重定向到另一个由 nginx 作为单独的静态文件服务器支持的 URL，只留下 Python 后端的图像选择逻辑。相反，来自客户端的 URL 请求应始终返回 image/jpeg，并在必要时在自定义 HTTP 标头中包含元数据。我指定它是因为它是一种避免从 Python 提供静态文件的方法，我想到了，其他人也可能想到 ;-)
鉴于这些信息，您认为哪种解决方案是好的选择，为什么？或者这是我需要为现有项目编写重要扩展的东西？
编辑：我一直在考虑这个问题。我不希望重定向，因为它们需要的多个请求固有的延迟，另外我想从客户端抽象出文件名，但我想知道这样的事情是否可能：
这是不言自明的，但想法是 Python 程序由 nginx（或任何服务角色）提供请求信息，仔细考虑，然后告诉 nginx 使用文件系统中的特定文件响应客户端的请求. 它这样做了。客户端对于请求是如何完成的并不明智，它只是接收到具有正确内容类型的响应。
在我看来，这将是非常理想的，但有可能吗？如果不使用 nginx，也许还有别的？