REST API的软件工程

Question

在我的上一个项目中，我们设计了一个问题文档系统组件（如错误报告工具），它应该集成到不同的客户端应用程序（桌面应用程序，移动应用程序以及独立的Webclient）中。重点不在于Application / UI本身，而在于其作为服务的功能。可以把它想象成Google Search API，它也可以集成到您的浏览器中，作为小部件，在手机上等等。

在定义功能（用例）和非功能性需求时，我很难定义它们而不需要特定于UI，因为我们希望获得一种服务。

作为一种解决方法，我们只是定义了我们的要求，以适应独立的Web应用程序以及所有函数调用必须通过RESTful Service API完成的非功能性要求，希望我们在使用此功能后不会遗漏任何函数例如，桌面应用程序中的API。事实上，我们实际上并不是首先想要一个webapp，而是一个服务，我对这种间接的需求分析方式并不满意，我希望我们的开发人员能够明白这一点。

所以我的问题是：REST API或Web服务是如何设计的，开发人员知道该怎么做？例如，是否有Web服务的UML UseCase配置文件？

Answer 1

查看software requirements specification的定义，您可以从产品使用的角度指定RESTful API作为技术要求，例如软件接口（即整体描述，产品视角，软件接口）。这不是功能要求。这只是您项目的技术要求。

没有UML用例配置文件，因为UseCase打算指定功能要求。考虑到常规用例中的功能访问和数据交换，您可以指定通过RESTful API访问系统的用户的交互。

应将预期RESTful API所需的所有特性指定为技术要求（即特定要求，External interface requirements）。考虑到应用程序的所有要求，开发人员知道该怎么做。

Answer 2

不要忘记：用例只是“整个故事的一半”

您还将具有非功能性要求。您无法使用用例捕获每个重要细节。

然后问问自己：用例是否适合我？

用例通常适用于“交互式系统”：与用户交互的系统。它们有助于捕获“功能”要求。

  

用例对某些系统不利。要心胸开阔。写作时   在您的使用案例中，您会发现这并未捕获您想要或未添加的内容   任何值尝试使用替代tecniques，例如plain   功能列表。

查找根本原因

问问自己“为什么在没有获取UI特定细节的情况下定义我的要求会遇到很大麻烦”？

选择你的战斗：质量Scenarious + Arhitectural Factor表

确定您在架构上具有重要意义的要求。定义它们的一个好方法是“Quality Scenarious”：

  

质量情景是[刺激]形式的简短陈述   [可衡量的回应]

例如：当一个新的错误报告输入到Bug系统[刺激]时，它会在X条件下在5分钟内发送给错误所有者的手机。[可测量的回复]

然后可以创建具有质量Scenarious的建筑因子表

  

Architectural Factor Table是一个帮助您理解的工具   因素，优先级和可变性的影响。

以下是Craig Larman一书中的因子表示例：应用UML和模式

“保证软件能够满足您的需求”......

首先编写测试...或者创建“可执行”规范...... 并沟通......

<强>最后

没有像REST API的软件工程那样。： - ）