What would be the best way to have a single REST API but with multiple "backends" (Not sure if this is the correct terminology)? Currently we have a basket/cart API that handles product creation, adding and removing products to a customer's basket, and handles all the checkout related stuff (Pricing, discount, instalments etc)

While this is good for us internally it doesn't integrate into any CRMs without exporting information out of it and into something like Shopify or Magento.

I would like to be able to skip our intermediate step and go straight to the CRM however I am unsure how best to go about designing something like this.

My current idea is an interface, say IBasketBackend, which has all the methods we need and each backend such as Magento or Shopify will implement this interface.

My idea is based on some parameter in the URL (most likely client ID), either build or retrieve an appropriate instance of IBasketBackend, however this seems like it would an a signifigant amount of overhead if it had to be done for each request.

  • How would this be a significant amount of overhead for each request? Your proposed design sounds reasonable to me. Commented Jul 2 at 12:52

1 Answer 1


Your last 2 paragraphs are the way to go.

No real overhead, especially if you cache any client specific meta data associated with each call.

Most likely you will have to write a façade for each back end to the interface. The CRMs are unlikely to have a common interface, let alone yours (which should be an abstraction of all providers).

  • Each request I would need to construct a new instance of IBasketHandler, do all of the authentication and then do whatever operation I need to do and then the request no longer exists and the interface is also cleaned up. Surely that would create a non-insignificant overhead?
    – gsck
    Commented Jul 2 at 12:55
  • 2
    Downstream authentication is part of the interface or implementation if stateless. How would you call the various back ends if you didn't authenticate? That's a given overhead, surely? Commented Jul 2 at 13:00
  • 2
    @gsck, authentication needs to happen regardless of which CRM you use. I would not consider that "overhead". It is simply a necessary part of the process. If the CRMs use a JWT, then you could try caching that for each client, but even then JWTs do not typically live very long. Until humanity stops hacking each other's computer systems, authentication will simply take a little time. Commented Jul 2 at 13:04
  • If you can measure that reaching out to the CRM for every request has a too high cost (in performance, latency, etc.) and there is no intrinsic need to reach the CRM every time, you could cache the CRM updates on your own system and only send them out at a point in the flow where it is logical to reach out to the CRM. Commented Jul 2 at 14:11
  • @gsck The instance itself and any other memory operations all sound like an insignificant overhead in the context of an HTTP request to a remote system (especially if the remote system also happens to be hosted elsewhere such as a cloud provider - then the difference in magnitude is greater still). Relativity is important - for example, when thinking about magnitude, consider something like the cost of a brand new car versus the cost of an air freshener to hang over the dashboard. Commented Jul 2 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.