Post History

The approach I would take given the constraints you've stated is to make much simpler and safer changes to Project A. Namely, 1) provide an API endpoint for fetching a file, and 2) provide an API endpoint, if needed, that takes some kind of "timestamp" (real or logical) and returns a list of files (optionally with some kind of checksum e.g. a MD5 hash) that have been added since that "timestamp" including any other metadata that's required.

As you've likely already gathered, Project B can then just fetch the list and then fetch files on its own schedule. It can refetch the list whenever it reaches the end of the current list or at any other time, e.g. if the Project B application is restarted.

The benefits of this approach is that it doesn't require any schema changes to Project A (assuming there's *something* already that can serve as a "timestamp"), and it's purely read-only from Project A. This avoids bloating Project A's database with file data that is not used by Project A. It also lessens risk of corrupting or breaking Project A, or even of needing downtime for it. It may also simplify throttling to avoid the "syncing" from being disruptive, if necessary.

On Project B's side, it's arguably less coupling to Project A. While accessing the file list endpoint is specialized to Project A, the file data endpoint can be generic and useful for other purposes. Even for syncing with Project A, it may be handy to be able to pull individual files on-demand outside of some background "syncing" process. Indeed, it's possible you could drop the file list endpoint entirely and do the file copying entirely on-demand.

This approach is basically the "read files directly from Project A's server" just mediated by Project A.

There may be different security requirements needed for these endpoints. You might be able to do something like IP address filtering since only Project B's web server needs access to these endpoints, though you can certainly use the same authorization mechanism you use for the other endpoints with just a "Project B" user or whatever.

This approach relies on the fact that the files are immutable. More coordination and complexity would be needed otherwise.