How to design a rest API that connects to other API's

Question

I'm having a architecture challenge. Simplified scenario:

We have a CRM-system (for now called This-Is-Our-CRM) that contains person data. We created a rest API so our data could be accessed outside of our own system.

Now our clients wants to be able to use the data available in This-Is-Our-CRM in multiple other applications. For example they want to mail these contacts through MailChimp and also be available in Salesforce.

Now I could do two things, but I'm not sure what is the best way.

Option 1: The API that has been created connects directly to the API of MailChimp and Salesforce. This means that our API is directly connected to these parties.

Option 2: The API we created just supply our data. So there must be another project that calls our API to get the data, and does a second call to Mailchimp / Salesforce so the data is available there.

Now I'm unsure to choose option 1 or option 2. With option 1 I'm a bit afraid that the API is continuously under heavy maintenance, because customers always want more applications to connect to. And I assume it's a bit more error prone, althrough I'm not sure about that.

So I'm currently thinking of option 2. My doubts about this option is that there will be multiple projects all for the same purpose; get the data from This-Is-Our-CRM to other applications. I do not want to add complexity where this is not needed.

Are here people having experience with one of these options? What are the advantages and disadvantages comparing to eachother?

Answer 1

Option 1 provides better security, as all requests must be routed through a gateway that you control.

Option 1 provides better maintainability; it is a single point of modification, and a simpler design. If you're worried about flexibility, use a plugin architecture to add new applications to it.

Option 2 provides less latency, as it only requires a single hop to get the data.

Answer 2

Both approaches are equally valid, for the reasons you already expanded on.

Additional thoughts:

Option 1 gives the organization the ability to address a problem once. Not every one who needs Salesforce or MailChimp data needs to know how the API and data structures work which could overall reduce development time and complexity.

Option 2 lends itself well for a Micro Services Architecture (MSA).

What I would do, is look at how much complexity can truly be reduced by the This-Is-Our-CRM © . For example if you can take a dozen methods down to a single simple query for something like ~This-Is-Our-CRM/GetLatestSalesFigure?ProjectName=DakotaRex it would potentially be worth it.

A risk here is what if a client needs a function that one of the clients offers out of the box, but no one else has needed until now. You might have to suddenly re-prioritize your own work to support adding this feature.

It might also make sense to go with Option 3 of some sort, where you offer a MSA end point/ gateway. If load ever becomes a real concern, scale / splitting of functions could happen invisibly to your clients.

Answer 3

Option 2 looks like the Microservices architecture and has the benefit of modularity and scalability. The downside of this approach is often complexity. For simple applications that don't need to scale well and are likely to remain a small code base option 1 is probably easier and faster.