便捷地说，API主导的衔接方法可以被看作是API设计的一种分层方法(至少在本文中是这样)。其中，系统API地下系统的资产数据信息;两边的是流程API，与系统API一同启动编排和组合;顶端的体验API地下来自后端数据源的数据，提供最终用户体验。这种API分层方法与细粒度SOA形式很好地联合在一同，通常，这两者要么可以共存，要么细粒度SOA形式演变成基于细粒度SOA的分层API形式。
API主导的衔接方法为细粒度SOA形式提供了一些档次结构，这些档次结构准许对API或微服务启动分歧的控制和控制。但是，基于细粒度SOA的分层API形式也存在一些与细粒度SOA形式相似的深层疑问(这很直观)：
在细粒度SOA形式口头单个API调用的中央，基于细粒度SOA的分层API形式如今必定经过层口头多个调用。从“网络跳数”的角度来看，这种形式或许是低效的。但是，基于细粒度SOA的分层API形式中，档次结构的存在并不强迫超过网络来调用每个API。间接的跨层调用，而不是经过网络调用是齐全有效的;分层的目的是为了参与灵敏性，同时以一种很好地分别关注点的形式构建体系架构。
在细粒度SOA形式控制少量服务的中央，经常使用分层API将会控制来自多个档次的少量细粒度服务。您的控制工具或许不再像以前那样有效，由于它们或许无法可视化复杂的微服务视图。
最终运行程序的数据存储分歧性在分层API形式下实践上获取了改善，由于访问数据的服务都是有组织，且集中地查问或修正运行程序的形态。(例如：系统API)
实践上，关于大少数企业来说，基于细粒度SOA的分层API形式是一个很好的形式，但是，就像细粒度SOA形式一样，在通常环节中会发生艰巨。但是，这种艰巨通常在大范围经常使用时才会浮现进去。因此，只要在预期或正在阅历大规模的经常使用时，咱们才应该预备其余的形式。
疑问：
没有必定档次结构的微服务架构是很难启动正当解释的，由于没有显著的方法来对每个微服务的用途启动分类和可视化。
处置打算：
经过创立按用途分组的分层API(系统层、流程及畛域模型层，以及体验层)，您可以更容易地控制微服务架构的复杂性。
运行：
将微服务架构分为多个层。通常状况下，可以经常使用规范化，并具备相似用途的一组微服务以相似的形式上班，从而进一步使微服务架构的复杂性正当化。
影响：
1.经过规范化和进一步合成微服务架构，可以提高极速变卦的才干。
2.由于更专门化的档次结构，进程间服务调用的数量或许参与。
3.须要对服务监控和可视化工具启动审核，以确定它们能否能够正确地与分层架构一同上班。
指标：
1.极速的矫捷变卦。
2.可伸缩性：通常上经过基于细粒度SOA的分层API形式可以提高可伸缩性，但实践上，除非有支持智能化的基础设备，否则可伸缩性往往会降落。
关键特点：
1.为了成功极速变卦，或许存在低效的IPC(Inter-Process Communication，进程间通讯)。
2.数据分歧性和形态控制才干较差，但准许高度重用。重用自身会对消变卦的速度。
3.由于与现存形式的相似性，已有的疑问往往雷同会发生。
4.基于细粒度SOA的分层API形式在小范围内经常使用成果很好，在大规模状况下会发生艰巨。
5.由于驳回了却构化的体系架构方法，所以具备很高的内聚性。
6.重点放在服务颗粒度要细，但通常没有思考其才干。
7.基于细粒度SOA的分层API形式以集成为导向，每个微服务依赖于外部系统。这将会降落变卦的速度。
基于细粒度SOA的分层API形式如何与SOA或API等现有系统共存?
基于细粒度SOA的分层API形式往往是与现有IT资产共存的最佳形式。由于分层缩小了每个微服务的范围，并解放了其用途，因此该形式能够在不显著降落变卦速度的状况下，最好地衔接和应用现有IT系统。但是，经过细粒度和分层的设计来协调变卦或许是一个应战。您或许须要经常使用必定的技术手腕来控制一切不同微服务之间的契约，或许经常使用齐全智能化的测试技术来确保变卦不会形成破坏。