Returning data to the user (Good API Design)

Question

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.

Answer 1

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?

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).

I've had trouble finding any information on the details of creating API's.

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.

Answer 2

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.