本系列的上一篇文章：发现SCP工作流–监视器。
本篇文章是系列文章的一部分，可在此处找到指南：发现SCP工作流。
在本篇文章中，我们探讨了处理工作流实例的SCP工作流API部分，并了解如何启动新的工作流实例，特别注意我们如何请求并使用跨站点请求伪造（XSRF）令牌。
在发现SCP工作流–监视器时，我们看到工作流API公开了以下主要实体：
工作流定义工作流实例用户任务实例消息
我们还了解工作流实例是给定工作流定义的特定实例。因此，人们可能会再次正确地猜测，由于工作流API是由REST原则通知的，因此我们应该查看工作流实例实体，以了解如何使用适当的HTTP方法启动新的工作流实例。
在API文档中，工作流实例的操作如下所示：
考虑到启动新的工作流实例肯定不是幂等的，我们的眼睛被吸引到：
当我们的眼睛在操作摘要上游荡时，它们也肯定落在为某些操作提供的路径信息上…因此我们可以推测工作流实例有上下文、错误消息和执行日志（实际上，我们查看了Discovering SCP Workflow（监视器）中的一些执行日志。也许我们会在另一篇文章中讨论这一点。
详细查看操作后调用的要求，我们可以看到以下内容：
这里的资源受到跨站点请求伪造的保护，每个请求中都需要提供一个XSRF令牌要提供的有效负载是JSON格式，有两个属性：definitionId：实际工作流定义的ID上下文：与要启动的特定工作流实例相关的数据
很高兴看到一个成功的响应以RESTful的方式返回HTTP状态码201。据我所知，通常伴随201响应的Location头丢失了（请求URL肯定不是新创建的资源的位置，在没有提供Location头的情况下，这是另一种选择）。但是让我们把这个问题留到另一个时间。
不管怎样，这个过程是相当简单的。让我们看一看Archana Shukla的文章"第2部分：从HTML5应用程序启动工作流"中的一些示例代码，以将流程嵌入到我们的大脑中。
首先，我们定义了
fetchToken函数：
这个◎fetchToken方法在main post方法之前被调用（即实际启动新实例的方法）。让我们仔细看一看。
有一个GET请求被发送到以下URL:
这个URL当然是由应用程序的neo中的目标条目抽象出来的-应用程序.json描述符文件，它的入口路径定义为"/工作流服务"：
题外话：资源URL和如何考虑它们
值得停下来简单考虑一下这意味着什么，以及我们如何看待这个工作流API（以及其他服务的API），特别是我们如何看待路径信息的不同部分。
顺便说一下，"路径信息"url的一部分，从主机名和（可选）端口之后开始，运行到任何查询参数。因此，例如，在URL
中，路径信息部分是：
所以，回到题外话。
当您在SCP驾驶舱中启用工作流服务时，会出现一个新的目标"bpmworkflowruntime"，其URL模式如下：对于生产帐户：
对于试用帐户：
因此，记住这一点，查看为工作流API生产URL定义的模式，如API Hub上工作流API文档的概述部分所述：
（拆分以便于阅读），我们可以看到"wfs"是提供者帐户名，
是工作流API资源路径信息的"根"部分。换句话说，这个"根"部分是工作流API中所有资源URL的公共部分。
以我的试用帐户为例，移动物联网卡，它解析为：
给定API资源（例如工作流实例）的完整URL如下：
您可以看到在路径信息的"根"部分之后，我们有特定于资源的部分：
这似乎是一种不必要的转移，但我认为理解资源标识符（URL）的结构非常重要，因此您可以以适当的方式考虑它们，将这种思想渗透到您的代码和配置中。
因此我认为在这里最好有这样一个目标条目：
其中"path"属性的值故意不同（这样我们就不会将它与实际的API资源路径信息部分混淆），"entryPath"属性的值反映了完整的"root"值"/工作流服务/rest"。因此，当我们在代码中构建依赖于这些目标抽象的相对URL时，我们只关注我们感兴趣的单个和唯一的资源名称，例如：
对我说
"工作流服务抽象提供的/v1/workflow instances API资源"。
我认为这比将资源名称与API根的某个部分混合在一起更好，而且某些内容（在我们的心目中）可能是或可能不是真实URL的一部分，看起来可能已损坏，因此容易混淆，比如这个例子：
这个离题有点学术性，绝不是对其他博客文章中代码的批评，但我认为至少值得分享一下我在这个问题上的想法。
不管怎样，让我们把离题留在那里，然后继续看XSRF令牌获取部分。再看一下上面的_fetchToken代码，我们看到向XSRF处理端点发出了一个httpget请求：
这里我要说的一件事是，XSRF和CSRF这两个术语之间存在不一致，这让我更加恼火，但除此之外，什么大数据，这很简单。
"请给我一个XSRF令牌"。
