将数据返回给用户（良好的 API 设计）
现在我已经开发了一个应用程序，我正在尝试为其编写 API。 理想情况下，应用程序会将字符串返回给用户。 API 无法以正常编程方式“返回”数据，因为应用程序发送的字符串数量可能未知。 在 Unix 系统上通过命名管道将此数据传递给用户是一个坏主意吗？ 我很难找到有关创建 API 的详细信息。 谢谢你的帮助。
So right now I've developed an application that I'm trying to write an API for. The application will ideally return strings back to the user. The API can not "return" the data in the normal programmatically sense because there may be an unknown amount of strings being sent from the application. On Unix systems is it a bad idea to pass this data to the user through a named pipe? I've had trouble finding any information on the details of creating API's. Thanks for any help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 Unix 上，程序通常通过将数据写入“标准输出”来输出其数据，想要多少数据就输出多少数据，也许是大量数据。 用户可以将此输出通过管道传输到屏幕或文件，或者将其作为输入传输到另一个程序（例如，该程序可能会过滤数据）。
http://www.faqs.org/docs/artu/ 相当有名，fwiw ： http://www.faqs.org/docs/artu/ch07s02.html #plumbing 说了一些关于使用管道将数据从一个程序输出到另一个程序的内容（带有一些示例）。
On Unix it's common for a program to output its data, as much data as it likes, maybe lots of data, by writing the data to 'standard output'. The user can pipe this output to th screen or to a file, or pipe it as input to another program (which might, for example, filter the data).
http://www.faqs.org/docs/artu/ is quite famous, fwiw: http://www.faqs.org/docs/artu/ch07s02.html#plumbing says something (with some example) about using pipes, to output data from one program into another program.
取决于应用程序。 如果它是一个短暂的命令行工具，那么从 stdin 读取/写入 stdout 模型就可以很好地工作。 grep/sed/awk/perl 将负责数据后处理。 如果它是一个守护进程，那么 fifo 或套接字可能是一个好主意，尽管您必须考虑该流上的某种客户端-服务器协议。 更进一步，提供一个了解该协议并为应用程序编写者提供一组一致的函数来与您的应用程序对话的库将是一个真正的 API。 这是典型的客户端-服务器，例如，大多数数据库都是这样工作的。
Depends on the application. If it's a short-lived command line tool, then read-from-stdin/write-to-stdout model works perfectly well. grep/sed/awk/perl would take care of the data post-processing. If it's a daemon, then fifo, or a socket might be a good idea, though you would have to think about sort of client-server protocol on that stream. Going one step further to providing a library that knows that protocol and gives application writer some consistent set of functions to talk to your app would be a real API. That's classic client-server, that's how most of the databases work, for example.