我正在从概念上重新设计项目，并且正在努力解决方法是否有意义。因此，为了避免意见和开放式讨论，我将尝试尽可能具体。
我们有几个网络应用程序（5+），每个都被视为产品。它们是相关的并且共享相似的数据 - 甚至到App1中的用户应该能够从App2引用或导入他/她的数据。在我看来，逻辑上有一个REST API，它充当数据模型和几个应用程序之间的层。通过这种方式，可以在API级别进行更改，并且可以在所有应用程序中进行更改（假设它保持向后兼容性）。
我正在尝试考虑如何设计此REST API以有效地与多个应用程序一起工作。以下是我的一些注意事项：
在考虑这个问题时，我希望API可以像api.example.com/v1和api.example.com/v2一样进行版本控制。我认为这对未来以及发展的进展非常重要。
这是一个问题领域。如果两个应用程序以不同方式使用用户资源会怎样？就像App1需要特定的处理和参数，但不是App2？我确信用户是一个不好的例子，因为它应该是相当标准的，但我可以看到发生冲突。那么我创建这样的命名空间吗？
在做类似的事情时，我将应用程序紧密地耦合到API。也许资源名称空间ID＃？
如果我需要对App1的命名空间API进行重大更改，如果全局增加版本，现在其他命名空间API在v2上，即使它们没有收到更改，该怎么办？我应该像这样切换命名空间和版本吗？
不幸的是，由于这些应用程序的性质，它们非常复杂。当然，在这种重写中，为了简化事情，很多使它们成为这种方式的东西被重构，但我们仍然需要某些似乎不适合其余模式的函数。像这样的方法调用是否有意义？
那些过于通用，很难想到手边的实际用例。
TL; DR 如何组织单个REST API作为多个不同应用程序和单个数据模型之间的中介？