我想将现有的 SOAP 服务器移植到 Delphi 中的 REST 框架中，并且我希望 REST 服务器可供以 Delphi 以外的其他语言编写的第三方应用程序使用。什么样的设计考虑因素很重要。例如
如果我在使用 Delphi REST 服务器向导时选择数据压缩，服务器是否仍可供 3rd 方应用程序使用，或者我是否需要自己压缩数据结构并使用字符串参数将这些结构传入和传出 REST 服务器？
我应该避免使用专有的 Delphi 参数，如 TDateTime，而是使用格式化的日期时间字符串吗？
我是否应该将 JSON 用于所有服务器通信，即所有以 JSON 编码的数据结构，或者可能是压缩的 JSON。
【问题讨论】：
我建议考虑的几点。
使用interface 定义服务端点——就像使用 SOAP 一样。不是面向 RAD 的方法，也不是属性 + 方法的方法。
使用 ISO-8601 JSON 字符串作为日期/时间，或 Unix TimeStamp（自 1970 年以来的整数，以秒或毫秒为单位） - 绝不是 TDateTime/OLE 浮点值。这两种第一种格式被所有客户端识别，包括 javascript。
依靠传输层（即 HTTP）进行压缩。我通常设置一个 nginx 反向代理，在 Linux 上运行，通过 Let's Encrypt 使用 gzip 压缩和 HTTPS，并让 Windows/Delphi 服务器通过 HTTP 提供原始 JSON，并与 Internet 进行适当的隔离。如果您希望客户端易于使用，请不要使用二进制布局（如 ProtoBuf）。 HTTPS+JSON 对于 90% 的用例来说已经足够快了。如有必要，只需使用适当的分页即可。
如果您想减少负载大小，请考虑使用使用 JSON 值数组而不是 JSON 对象的备用端点。它的问题在于它的可维护性较差：很难使其发展。一些框架（比如我们的 mORMot）允许两种布局。
准备从第一个发布的 API 进行版本控制。最简单的方法是为每个修订版定义一个 interface，可从 server.com/v1 然后 server.com/v2 URI 访问。
不要泄露您的业务模型（即您的原始数据结构，例如您的 SQL 表）。为 REST 服务定义 DTO，作为数据结构的精简版本。这些 DTO 应该以客户端为中心（客户端在给定用例中想要什么？），而不是以服务器为中心（我可以发布哪些数据？）。每个用例使用一个接口。例如，您可能有多个“用户”端点，具体取决于使用的上下文。一个单一的 REST 服务器来统治它们是很难维护和使用的。
您的 REST 框架应该能够为客户端生成客户端代码和文档。大摇大摆的帮助。
准备好为服务器部分切换到 FPC。它的 Linux/BSD 和 ARM/AARCH64 支持非常出色，因此它可以增强您重构的服务器代码的长期维护。
考虑设计硬端点的状态。定义例如至少是微服务，如果您的项目满足其要求，甚至是领域驱动设计。至少看看这些设计 API 的方式。从服务器的角度来看，朴素的 REST 方法很容易开始，但很难使用和发展。永远不要直接映射数据库！
考虑到 REST 服务器的多线程能力。扩展是通过利用 HTTP 服务器的多线程和业务逻辑来实现的。
考虑发布 WebSockets 端点以进行实时通知。最终用户现在习惯于使用响应速度非常快的应用程序，并在屏幕上显示实时更新。
从头开始使用测试。使用 interface 将有助于模拟/存根您的服务。
当然，我们的Open Source mORMot framework 就是为这种过程而设计的。只需谷歌寻找替代品。
【讨论】：