开源项目 Spartacus Storefront 使用到的 OCC API 介绍

Commerce Cloud提供了一组称为Omni Commerce Connect(简称OCC)的Restful API.

Spartacus通过标准的HTTP协议调用这组API，实现同Commerce Cloud交互的目的。从编程层面来说，100%的API驱动确保了Spartacus的前后端分离，使得Spartacus的二次开发人员不需要去了解Commerce平台Java层的实现细节，而过去基于Commerce Accelerator技术的Storefront二次开发，需要的是会使用JSP和Java的全栈开发者。

从更深层次来说，100% API驱动使Spartacus同Commerce平台也解除了紧耦合关系，从而极大提升了Spartacus的可升级性。这一点在接下来Accelerator同Spartacus的对比中我们会进一步说明。

Spartacus的代码是完全开源的，托管在Github上。如果大家细心察看Github仓库上的代码提交者列表，就会发现，这些代码贡献者有的是像Jerry这样的SAP职员，有的来自partner公司，还有freelancer即自由职业者。SAP选择将Spartacus开源，希望构建出一个繁荣的生态圈，和开源社区里其他贡献者共同在Commerce Storefront领域进行持续创新。

那么，SAP为什么要推出Spartacus呢？这得从Spartacus诞生之前，SAP Commerce传统的Storefront实现技术即Accelerator说起。

Accelerator是Spartacus发布之前，SAP Commerce Cloud使用的Storefront实现技术。

Accelerator是一个开箱即用的web实现模板，是Commerce平台的一部分，以源代码的方式交付给客户。客户通过一个叫做module generator的工具，基于Accelerator 模板代码生成自己的Storefront实现，然后基于这些生成的代码继续二次开发。这种源代码生成方式确实能加快客户的Storefront二次开发速度，这也是Accelerator命名的由来。

然而，Accelerator这种同Commerce平台的紧耦合关系，以及基于源代码级别的二次开发方式，给Commerce项目实施的可升级性带来很大的挑战。例如，当客户发现新版本的Accelerator能满足自己新的业务需求时，希望升级Accelerator. 然而由于Accelerator是Commerce平台的一部分，所以必须先升级整个Commerce系统，再使用module generator基于高版本的Accelerator代码，重新生成自定义实现，再把基于低版本Accelerator模板而进行的二次开发内容，逐一手动地迁移到高版本Accelerator生成的自定义实现中去。

当Commerce的二次开发达到一定规模量的时候，这种手动升级的方式很挑战。

Accelerator具有的这些缺陷，在Spartacus问世之后都迎刃而解。

Accelerator通过源代码的方式提供了一个Storefront的开发模板，而Spartacus则以库的方式，提供了一个轻型的Storefront开发框架。我们新建一个Angular应用，导入对Spartacus库的依赖，当我们需要升级Spartacus时，只需要更新Angular应用的package.json文件里Spartacus库文件的版本号即可，因此Spartacus从可升级性上来说是一个巨大的飞跃。