从mft到api风格来获取或发布大数据200 it，这是最佳实践吗？

Question

我正在为我的客户设计API架构：

我的客户实际上与他的MFT ( SFTP )合作伙伴交换了大量文件(csv)。

• **合作伙伴==> MFT ==>客户端**

要求移到API REST交换模式以替换MFT ( csv文件)。

• **合作伙伴==> API ==>客户端使用GET API **

例如：

我客户的合作伙伴每天发送200 MB的文本数据( csv文件200 000行)。

实际上，我的客户端是通过MFT接收到的，他问我是否最好用API REST调用来代替它来传输大数据(订单为200 me )。

我知道正常有效负载的最佳实践是一个调用HTTP的1MB( json有效负载)，所以我将执行分页(200页)和处理错误等等。

• 通过API来实现这一点是一种最佳实践吗？
• 对此是否有详细的/实际的论据(为什么在这种情况下我们应该使用API，我的客户总是这样问我)？
• 在保持性能的同时，是否有技术在传输数据200 MB (我估计200页和200 http调用以获取所有数据)的同时减少分页？

Answer 1

在您的图表中，数据流向哪个方向有些不清楚。您的箭头是双向的，这是否意味着每个参与者发送和接收文件？还不清楚是哪个方启动了传输，哪个方运行了服务器，以及数据是被提取还是推送。

构建REST服务的HTTP在拉场景中通常具有很好的性能，因为这是web中的主要使用模式。如果可以通过正常的HTTP请求获取文件，那么这可能是性能和简单性方面的最佳解决方案。分页很可能是不必要的，如果您使用内容压缩，那么在传输期间200 is的CSV文件可能不到100 is，使用单个HTTP请求这有点大，但并非不可能。

如果合作伙伴不能在服务器上提供文件，则需要使用一个push模型，这个模型可能更复杂，速度更慢，除非您可以在一个POST请求中使用压缩方式传输文件。它一直被用于在网络上上传图像，所以它通常也得到很好的支持。

请注意，RESTful端点不需要仅限于JSON数据，使用文本/csv内容类型是完全可以的，而且这个端点的实际实现可能直接在web服务器中(如果它能够正确处理授权内容)，所以您不需要使用某些应用程序REST框架，尽管这仍然是可能的。

Answer 2

通过API这样做是最好的实践吗？

不，一种看法是，REST的一部分是在客户端和服务器之间设置缓存。以一种方式传输文件意味着不需要缓存，因此不需要REST。

您不希望有一个用于传输文件的自定义API。有许多数据集成工具只需使用FTP、SFTP、FTPS等就可以做到这一点。