REST API的软件工程

Question

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

在定义功能性(用例)和非功能性需求时，我遇到了很大的麻烦，因为我们想要得到一种服务，所以在没有特定UI的情况下定义它们。

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

所以我的问题是: REST API或way服务是如何设计的，以便开发人员知道该怎么做？例如，是否有用于for服务的UseCase？

Answer 1

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

你会有non-functional需求，also.You不能捕获用例的每一个重要细节。

然后问你自己:用例适合我吗？

用例通常适用于“交互式系统”：与user.They进行交互的系统非常适合捕获“功能性”需求。

用例不适合某些系统。保持开放的心态。在写你的用例时，你会发现这并不能捕捉到你想要的东西，也不会增加任何价值，比如使用简单的功能列表等替代技术。

查找根本原因

问问你自己“为什么我遇到很大的麻烦来定义我的需求，却没有得到UI特定的细节”？

挑起战线: Quality Scenarious +建筑结构系数表

确定您在架构上有意义的需求。定义它们的一个好方法是"Quality Scenarious"：

质量场景是形式刺激的简短陈述

例如:当新的bug报告进入Bug系统刺激时，它将在5分钟内在X conditions.measurable响应下发送到bug所有者的手机

然后，可以使用Quality Scenarious创建体系结构因子表

架构因素表是一个工具，可以帮助您了解因素、优先级和可变性的影响。

下面是Craig Larman的书《应用UML和模式》中的一个示例因子表

​

​

“保证软件能做你想做的事”...

因此，编写您的测试first...Or创建“可执行”规范...并进行交流。

最终

没有什么比REST API的软件工程更好了。：-)

Answer 2

查看software requirements specification的定义，您可以从产品使用的角度将RESTful应用编程接口指定为技术需求，例如软件接口(即总体描述、产品透视图、软件接口)。这不是功能需求。这只是你的项目的一个技术要求。

没有统一建模语言用例概要文件，因为UseCase打算指定功能需求。考虑到常规用例中的功能性访问和数据交换，您可以指定通过RESTful接口访问您的系统的用户的交互。

预期的RESTful应用程序接口所需的所有特性都应指定为技术要求(即特定要求，External interface requirements)。考虑到应用程序的所有需求，开发人员知道要做什么。