Another developer and I are integrating two systems that are private to a client and that have duplicate functionality, so we are looking to save users the time of inputting the same data into both systems. His system runs on localhost at the client site while mine runs on the cloud, so we plan for my system to expose a REST API for his system to call. In many cases, his system will be saving data on my system. For example, client records.
I see two options for how this could work:
Option 1: He sends an id to my system to relate with the new client record - for example {client_name: 'Ballmart', id: 'FD23949fsad293fa2'} and then sends the same id when he wants to reference it - for example when adding a new order: {orderNumber: 2393, clientId: 'FD23949fsad293fa2'}
Option 2: He sends a client record with no id, and I respond with my id to his request. He saves my id in his database, and sends it over when he needs to reference a client record. So he would send {client_name: 'Ballmart'}, I would respond with {id: 'FD23949fsad293fa2'}, and then he would send {orderNumber: 2393, clientId: 'FD23949fsad293fa2'} as before to record a new order for the client.
My hunch is Option 2 is better but I am struggling to rationalize why.
His system is larger and has more functionality. He is also a full time employee while my contract will be up soon, at which point he will need to take more responsibility for managing my system.
I would say the system in charge of the data ("master") is the one which should create the ID (for example to avoid duplicates, or not to book an ID for a cancelled creation)
Moreover, the second option looks more like a REST POST request, which is now a kind of standard for understanding the API
*** After discussion through comments: ***
If the next phase is that the main system owns all the data, design the solution with this in mind. Choose option 1 and do not make the integration effort on the main system (especially the data structure), from where you would have to remove it later.
Moreover the exchanges you describe look like a one-way replication. In this case I think a "origin" or "reference" column on the destination tables is the best way, especially if the main system must replicate on yet other systems.