如何根据ID获取实体的servicePath？
我也有一些关于服务路径的设计问题：
总而言之，建议完全使用服务路径？
由于
答案 0 :(得分：2)
我认为这是不可能的，正如您在this presentation的Multitenancy部分所看到的那样。
此外，对于不同的Entity ID和Fiware-Services，您可以拥有相同的Fiware-ServicePaths。
Attributes非常灵活。当您需要分开内容（例如OpenStack的Fiware-Service和Fiware-ServicePath）时，Projects和Domains是必需的。
如果您使用Fiware-Service和Fiware-ServicePath创建实体，则需要在执行GET和DELETE操作时指定这些标头。如果你得到与此不同的东西，我想也许你正在做一些奇怪或遗失的事情。
当您使用Fiware-Service和Fiware-ServicePath时，您的应用程序已经知道了这些信息。所以，你不必发现它。只需使用右entity和Fiware-Service标题的Fiware-ServicePath。
我希望这可以帮到你。 @fgalan，如果我回错了，请纠正我。
答案 1 :(得分：1)
我会尝试内联回答您的问题，作为@Dalton已经提供的答案的补充。
如何根据ID获取实体的servicePath？
当前的Orion版本（1.7.0）并未将其作为API的一部分实现。它假定客户端应用程序已经知道要使用哪个服务路径。但是，它已被确定为a future enhancement的一部分。
请注意，可能相反，即检索给定servicePath的所有实体。例如：
GET /v2/entities
Fiware-ServicePath: /A
为什么它被实现为HTTP标头？如果它是一个属性会更简单。
因为它旨在成为FIWARE中的跨GE多租户机制。请注意，“属性”的概念对Orion Context Broker有意义，但其他GE使用不同的概念。使用HTTP标头以API无关的方式为所有FIWARE GE保持相同的机制。
免责声明：话虽如此，请注意目的在于，而不是 。我的意思是，我不确定其他GE（除Orion之外）目前是如何在FIWARE中实现的。
用法似乎被破坏了：例如我可以使用默认服务路径获取实体，但之后我无法删除它，因为它可能属于不同的服务路径。
API无法被探索：我可以发现一个实体，但后来我无法做任何事情，因为我不知道它的服务路径。
如上所述，当前实现假设客户端应用程序已经知道要使用哪个服务路径。考虑到这一点，我理解您在上述两个问题中提到的问题不会发生。
总而言之，建议完全使用服务路径？
这取决于用例。如果您可以假设客户端应用程序已经知道要使用哪个服务路径或者存在隐式服务路径结构（例如，您的服务路径是西班牙的城市，/Madrid，/Barcelona等。 ）那么它可以是一种有趣的结构化上下文信息的方式。
有关服务路径的更多信息，请参阅Orion Context Broker documentation。