Requests and responses from and to the local filesystem are typically (and unsurprisingly) concerned with reading and writing data from and to local files. The simplest request-and-response structure of this type is a service that reads data from one file, processes it, and writes the results out to another file, possibly deleting or flushing out the incoming file on every read, and either replacing the output file on every write, or appending to it as each response is generated and returned. Implementations for single input and output files may leverage the stdin and stdout functionality of Python's sys module, or override either (or both) of them.

Both Windows and POSIX operating systems (Linux, macOS) have special file types, called named pipes, that reside on the filesystem and act like files, in that they can be opened, read from, and written to by using standard file-access code. The main difference is that a named pipe file can be opened and written to/read from by multiple different processes at the same time. That, then, allows for any number of processes to add requests to a file, queuing them up for a service to read and handle. Named pipes can also be used for service output.

Another variant is monitoring for changes to files in the local filesystem, including the creation of new files, and changes to (or even the deletion of) existing files in a given location. At its most basic, this would involve generating and maintaining a list of files to keep track of, and periodically checking the actual filesystem structure for those files' existence and modified time. An implementation that follows this pattern might have a common input-file directory, and, as each iteration through the main service loop occurred, it would check for new files, read them, execute, and remove the file once processing was complete (in order to keep the number of files being monitored reasonably small).

For scenarios where the number of files being monitored is large enough that creating and refreshing that list is too computationally expensive to be practical, monitoring filesystem events with functionality from the pyinotify library is a viable alternative, though there have been differences in what's available between POSIX/Linux and Windows versions of the library.