Delphi REST服务器和第三方应用程序

我希望将现有的SOAP服务器移植到Delphi中的REST框架，并且我希望REST服务器能够被用Delphi以外的语言编写的第三方应用程序使用。什么样的设计考虑是重要的。比如说

如果我在使用Delphi REST Server向导时选择了数据压缩，那么第三方应用程序是否仍然可以使用服务器，或者我是否需要自己压缩数据结构，并使用字符串参数将这些结构传递给REST服务器或从REST服务器传递这些结构

我应该避免使用专有的Delphi参数，比如TDateTime，而是使用格式化的日期时间字符串吗

我是否应该在所有服务器通信中使用JSON，即所有以JSON编码的数据结构，或者可能是压缩的JSON

---

<> P>一些我建议考虑的要点。

使用

interface

定义服务端点-就像使用SOAP一样。不是面向RAD的方法，也不是属性+方法的方法

使用ISO-8601 JSON字符串表示日期/时间，或使用Unix时间戳（自1970年以来的整数，分辨率为秒或毫秒）-从不使用TDateTime/OLE浮点值。包括javascript在内的所有客户端都可以识别前两种格式

依赖传输层（即HTTP）进行压缩。我通常设置一个运行在Linux上的nginx反向代理，通过Let's Encrypt使用gzip压缩和HTTPS，让Windows/Delphi服务器通过HTTP提供原始JSON，并与Internet适当隔离。如果希望客户端易于使用，请不要使用二进制布局（如ProtoBuf）。HTTPS+JSON对于90%的用例来说足够快。如有必要，只需使用适当的分页即可

>P>如果要减少有效载荷大小，请考虑使用JSON值数组代替JSON对象使用备用端点。它的问题是，它的可维护性较差：很难让它进化。一些框架（比如我们的mORMot）允许这两种布局

准备从第一个发布的API进行版本控制。最简单的方法是为每个版本定义一个

接口

，可从server.com/v1然后从server.com/v2 URI访问

不要泄露您的业务模型（即原始数据结构，例如SQL表）。将REST服务的DTO定义为数据结构的精简版本。这些DTO应该以客户机为中心（客户机在给定用例中想要什么？），而不是以服务器为中心（我可以发布哪些数据？）。每个用例使用一个接口。例如，根据使用的上下文，您可能有多个“用户”端点。单一的REST服务器很难维护和使用

您的REST框架应该能够为客户端生成客户端代码和文档。大摇大摆有帮助

准备好能够为服务器部件切换到FPC。它对Linux/BSD和ARM/AARCH64的支持非常出色，因此它可以增强对重构服务器代码的长期维护

考虑设计硬端点的状态。如果您的项目满足其要求，则至少定义微服务，甚至域驱动设计。至少看看这些设计API的方法。简单的REST方法很容易从服务器的角度出发，但很难使用和发展。永远不要直接映射数据库

考虑REST服务器的多线程能力。扩展是通过利用HTTP服务器的多线程和业务逻辑实现的

考虑发布WebSockets端点以获得实时通知。终端用户现在习惯于使用响应速度非常快的应用程序，在屏幕上实时更新

使用从头开始的测试。使用

接口

将有助于模拟/存根您的服务

当然，我们的产品是为这种工艺设计的。只需谷歌搜索替代方案