写在最前面，五五开，老师讲的很好，不点名，最离谱的时候只来了十个人，老师也没说什么，我记得选了小一百的人，2333333333，期末比较简单，贝多芬，适合摸鱼，刷GPA
简答题：8*5
服务中三角色三作用
服务在软件互操作中的作用
ROA RPC的区别
可以体现SOA的三项协议。
构建Restful服务的步骤
什么是幂等性举出http动词幂等性的例子？
微服务中的特点。
为什么需要open API？
陈述题：15*4
在618期间，你的网站可能需要承受十倍的访问量，你作为网站的设计者，你应该怎样设计相关资源，并给出体现的Restful服务设计思想
Restful服务的安全性*3，举出例子
什么是资源？
资源表述的转移是什么？
Restful服务适用于哪些场景并举出例子？
给出一行代码，让你解释它的含义，
并指出注释（@PATH@POST@Produces@PathParam）的意义。
import javax.servlet.http.HttpServletRequest;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
@Path("/user")
public class UserController {
@POST
@Path("/{id}/{username}/{telephone}")
@Produces(MediaType.APPLICATION_JSON)
public Response createUser(@PathParam("id") String id,
@PathParam("username") String username,
@PathParam("telephone") String telephone,
@Context HttpServletRequest request) {
// 从路径中获取参数
String pathInfo = request.getPathInfo();
// 解析路径参数
// 将参数封装为 JSON 对象
JsonObject jsonObject = Json.createObjectBuilder()
.add("id", id)
.add("username", username)
.add("telephone", telephone)
.build();
// 返回 JSON 响应
return Response.status(200).entity(jsonObject.toString()).build();
}
}
知识点：
2.1 支撑 Web 迅速发展的四个基石技术是什么？
2.4 简述 ROA 模式与 RPC 模式服务的主要区别。
2.5 解释何为表述性状态转移 REST。
2.6 概述 RESTful 服务的优势。
2.7 解释何为幂等性？哪些 HTTP 操作具备幂等性？
2.8 解释服务的“无状态性”对于分布式应用的重要性。
3.1 如何理解资源的本质？
3.2 如何理解表述的本质？
如何理解资源与表述的关系？
传统API和RESTful API是两种不同的API设计风格，它们有以下几个区别：
1. 架构风格：传统API通常基于RPC（Remote Procedure Call）或SOAP（Simple Object Access Protocol）等技术，而RESTful API则基于REST（Representational State Transfer）架构风格。
2. URI设计：传统API的URI设计通常基于操作或方法，如/getUser、/createOrder等，而RESTful API的URI设计应该基于资源，如/users、/orders等。
3. HTTP方法：传统API通常使用POST、GET、PUT和DELETE等HTTP方法来执行不同的操作，而RESTful API则严格遵循HTTP协议定义的方法，如GET用于获取资源，POST用于创建资源，PUT用于更新资源，DELETE用于删除资源等。
4. 表述格式：传统API通常使用XML或JSON等格式来传输数据，而RESTful API则更加灵活，支持多种数据格式，如JSON、XML、HTML、txt等。
5. 状态管理：RESTful API强调资源的状态转移，即通过HTTP方法来实现系统状态的转移，而传统API则更加依赖于服务器端的状态管理。
总的来说，RESTful API相对于传统API更加灵活、简洁，并且更符合HTTP协议的设计原则。RESTful API通常遵循资源的概念，通过URI和HTTP方法来实现系统状态的转移，使得API设计更加清晰、易于理解和扩展。
- ROA和RPC的区别
RPC 模式的服务本质上是对过程调用的“远程化”，实现起来相对更加灵活
ROA 架构下，都是基本的 HTTP 操作 仅就消息形式上看，ROA 相比 RPC 消息，也明显的更加简洁
- 资源、资源的表述、资源表述状态转移的关系
资源是一个很宽泛的概念，任何寄宿于 Web 可供操作的“事物”均可视为资源，就其 本质而言，任何足够重要并被引用的事物都可以是资源。（URI的都可以为资源）
所以资源的表述实际是一段对于资源（在 某个特定时刻的）状态的描述；客户端请求资源，往往也是想得到资源的当前状态。
在RESTful架构中，资源是核心概念之一，资源的表述和状态转移也是RESTful架构的基本特征。它们之间的关系如下：
1. 资源：在RESTful架构中，资源是指网络上的任何信息实体，可以是一个文件、一张图片、一段文字、一个对象或者任何可以命名的事物。每个资源都有一个唯一的标识符（URI）来表示它在网络上的位置。
2. 资源的表述：资源的表述是指资源的具体内容，可以是XML、JSON、HTML或任何其他格式的文本。在RESTful架构中，客户端通过请求资源的URI来获取资源的表述。
3. 状态转移：在RESTful架构中，客户端与服务器之间的交互是通过HTTP协议完成的，其中包括GET、POST、PUT和DELETE等请求方法。这些请求方法用于对资源进行状态转移，即客户端通过请求方法来操作资源的表述，使资源的状态发生变化。
- 资源表述状态转移的关系：在RESTful架构中，客户端通过请求资源的URI来获取资源的表述，然后使用HTTP请求方法对资源进行状态转移。客户端发送的请求中包含了资源的表述和请求方法，服务器根据请求方法对资源进行操作，并将操作结果返回给客户端。因此，资源、资源的表述和状态转移之间是密切相关的，它们共同构成了RESTful架构的基本特征。
- HTTP中HEAD的作用
HEAD，得到描述目标资源的报文头部数据信息
在HTTP协议中，HEAD方法是一种请求方法，它与GET方法的行为类似，但是不返回响应体。HEAD方法通常用于查询服务器上的某个资源的元信息，而不需要获取实际的资源内容。HEAD请求的响应只包含响应头信息，而不包含响应体信息。
HEAD方法的主要作用如下：
1. 获取资源元信息：通过HEAD方法，客户端可以向服务器查询某个资源的元信息，例如资源的类型、大小、修改时间、最后修改者等信息，而无需获取实际的资源内容。
2. 验证资源是否存在：通过HEAD方法，客户端可以向服务器验证某个资源是否存在，而无需获取实际的资源内容。如果服务器返回了200 OK的响应，说明该资源存在，否则说明该资源不存在。
3. 验证资源是否有更新：通过HEAD方法，客户端可以向服务器查询某个资源的最后修改时间，从而判断该资源是否有更新。如果服务器返回的最后修改时间与客户端保存的最后修改时间不同，说明该资源已经有更新，客户端可以通过GET方法获取最新的资源内容。
总之，HEAD方法是一种用于查询资源元信息、验证资源是否存在以及验证资源是否有更新的HTTP请求方法，它可以提高客户端与服务器之间的通信效率，减少网络传输的数据量。
- 常见HTTP中安全的操作
HTTP 的 GET、HEAD 请求本质上应该是安全的调用，即：GET、HEAD 调用不会有任 何的副作用，不会造成服务器端状态的改变。对于服务器来说，客户端对某一个 URI 指代 的资源执行 1 次或者多次的 GET、HAED 操作，其状态与没有执行操作是一样的，资源本身的状态不会发生任何的改变。这就好比我们打开一个只读文件，不管打开多少次，其内容 都不会发生变化。
- 服务开发设计的基本步骤
服务开发设计的基本步骤可以分为以下几个阶段：
1. 需求分析：在这个阶段，需要了解用户的需求和服务的功能，确定服务的范围和目标用户群体，分析用户需求和服务的特点，并制定服务的功能规格说明书。
2. 架构设计：在这个阶段，需要确定服务的架构，包括服务端技术栈、数据存储方案、通信协议、安全策略等。同时还需要对服务进行模块划分，确定模块之间的接口和数据交互方式，并设计服务的API和UI界面。
3. 实现开发：在这个阶段，需要根据架构设计和功能规格说明书，进行服务的实现开发。开发过程中需要按照开发规范和代码风格进行编码，实现模块之间的数据交互和接口调用，并进行单元测试和集成测试，确保服务的功能和性能符合需求。
4. 部署和运维：在服务开发完成后，需要进行部署和运维工作。这包括将服务部署到生产环境中，进行性能测试和负载测试，确保服务能够稳定运行。同时还需要建立监控和报警系统，及时发现和解决服务故障，并进行版本控制和升级。
5. 维护和升级：在服务运行过程中，需要对服务进行维护和升级，包括解决服务故障、优化服务性能、修复漏洞和升级功能等。这个过程需要不断地进行测试和验证，确保服务的稳定性和安全性。
综上所述，服务开发设计的基本步骤包括需求分析、架构设计、实现开发、部署和运维以及维护和升级，每个阶段都需要进行详细的规划和实施，才能确保服务的质量和用户满意度。
- 如何开发前后端分离项目
前后端分离是一种新型的开发模式，它将前端和后端的开发分离，让前端和后端分别独立地进行开发，从而提高开发效率和灵活性。下面是从服务开发的角度，如何开发前后端分离项目的基本步骤：
1. 确定服务端技术栈：根据项目需求，选择适合的服务端技术栈，例如Spring Boot、Express、Django等。同时需要确定服务端的API接口规范，例如RESTful API或GraphQL。
2. 设计数据库和API接口：根据项目需求，设计数据库表结构和API接口，确定数据模型和业务逻辑，编写服务端API接口文档，方便前端开发人员调用。
3. 开发服务端API：根据API接口规范和数据库设计，开发服务端API接口，实现数据的增删改查等功能，并且编写单元测试和集成测试，确保API接口的正确性和稳定性。
4. 开发前端应用：根据API接口文档和UI设计图，开发前端应用，实现用户交互和数据展示等功能。前端应用可以使用常见的框架和库，例如React、Angular、Vue等。
5. 集成部署：将前端应用和服务端API进行集成部署，可以使用Nginx或Apache等Web服务器进行反向代理和负载均衡，确保应用的可靠性和高可用性。
6. 测试和发布：进行系统测试和用户验收测试，确保应用的质量和用户满意度，然后进行发布。在发布后，需要进行监控和维护，及时发现和解决问题，确保应用的稳定性和安全性。
总之，开发前后端分离项目需要注意服务端技术栈的选择、API接口的设计和开发、前端应用的开发、集成部署、测试和发布等环节，同时需要进行协作和沟通，确保项目的进度和质量。
- OpenAPI有何作用
OpenAPI是一种用于描述RESTful API的规范和工具集，它可以帮助开发者更好地设计、开发、文档化和测试API。OpenAPI具有以下几个作用：
1. API设计和开发：OpenAPI可以帮助开发者更好地设计API，包括API的请求和响应格式、参数、错误码等信息。开发者可以使用OpenAPI定义API的结构和规范，然后使用工具集生成API代码框架，从而加快API开发速度。
2. API文档化：OpenAPI可以生成API文档和交互式API浏览器，使得API的使用者可以更加方便地了解API的功能和使用方法。API文档包括API的请求和响应格式、参数、错误码、访问权限等信息，帮助开发者快速上手。
3. API测试：OpenAPI可以自动生成API测试用例，帮助开发者进行API测试。开发者可以使用OpenAPI定义API的请求和响应格式，然后使用工具集生成测试用例，从而快速进行API测试，确保API的正确性和稳定性。
4. API管理：OpenAPI可以帮助开发者管理API的版本、权限、访问控制等信息。开发者可以使用OpenAPI定义API的版本和访问控制规则，从而管理API的访问权限和版本迭代。
5. API扩展和整合：OpenAPI可以帮助开发者扩展和整合API，包括将多个API整合成一个API、将API扩展到其他平台和设备等。开发者可以使用OpenAPI定义API的结构和规范，从而进行API的扩展和整合。
综上所述，OpenAPI是一种用于描述RESTful API的规范和工具集，它可以帮助开发者更好地设计、开发、文档化和测试API，从而提高开发效率和API的质量。
- 微服务设计中的微服务有何特点（至少2个）
首先，单体应用将系统所有的逻辑都放到一起，所有的功能模块都整合在一起，逻辑复 杂，代码臃肿，任何一个模块出现异常，都可能会导致应用服务器宕机；一旦系统需要扩展， 不管是功能扩展还是性能扩展，对于单体系统难度都很大，尤其是性能扩展，只能把整个单 体应用复制到多态服务器上；而微服务架构将单个服务对应到单个业务功能，方便理解、开 发和维护。
其次，服务独立部署，可以根据每个服务的请求量来部署满足需求的规模；在需要添加 新功能的时候，可以独立进行开发，随时更新、部署，不会影响其他线上的服务。
此外，因为微服务之间并不是直接耦合在一起，而是通过网络通信进行服务之间的相互 调用，开发者也不必统一开发语言、技术栈等，开发过程会更加灵活，对技术学习的成本更 低
- RESTful 服务的优
使用统一的接口操作资源
接口更易于使用
无状态性
安全操作与幂指相等特性
更容易实现缓存
更适合开放 API 场景
二、收银员通过咖啡杯和咖啡师交流的案例
（1）体现了什么设计思想（5分）
RESTful 服务设计 微服务设计思想 解耦合 弹性设计
（2）对服务开发有什么启示（10分）
1. 咖啡师忙不过来了——通过缓存提升可伸缩性
2. 无状态性
3. 异常处理
4. 善用状态码
1）提升效率的关键是解耦，用户不与咖啡师见面，任何咖啡师可以服务任何顾客，这 也是软件服务化的出发点。
2）系统灵活的关键是无状态，本案例通过咖啡师缓存提升了可伸缩性，服务系统中通 过横向扩展服务实例实现了系统的弹性。
3）运转的关键是表述性状态转移，通过咖啡订单表述传递顾客需求到完成咖啡的各个 状态。
4）善用链接，这就是“链接”成为引擎（HATEOAS）的意义。
（1）要设计什么资源（5分）
（2）资源有哪些操作（10分）
(1) 要设计的资源包括：
- 机场资源（Airport）：表示机场的信息，包括机场名称、机场代码等。
- 航班资源（Flight）：表示航班的信息，包括航班号、起飞时间、降落时间、起飞机场、降落机场、状态等。
- 航班状态资源（FlightStatus）：表示航班的状态信息，包括延误时间、取消原因等。
(2) 资源的操作包括：
- 查询机场列表（GET /airports）：获取机场列表信息。
- 查询航班列表（GET /flights）：根据起飞/降落时间、航班状态等条件查询航班列表信息。
- 查询航班详情（GET /flights/{flight_id}）：根据航班号或航班ID获取航班的详细信息。
- 更新航班状态（PUT /flights/{flight_id}/status）：更新航班的状态信息，例如延误时间、取消原因等。
- 创建新航班（POST /flights）：创建新的航班信息。
- 删除航班（DELETE /flights/{flight_id}）：删除指定的航班信息。
其中，查询机场列表和查询航班列表是比较常用的操作，查询航班详情和更新航班状态则是针对单个航班的操作，创建新航班和删除航班则是管理航班信息的操作。通过这些操作，可以实现对机场航班列表的查询、管理和维护。
1. 该服务实现了一个简单的HTTP GET请求处理，当客户端通过访问URL中的特定用户名时，服务器将返回一个包含该用户名的问候消息，类似于：Hello username。
2. 四个注解的作用如下：
- @GET：这个注解指定了这个方法将处理HTTP GET请求。当客户端通过HTTP GET请求访问这个方法所在的URL时，服务器将调用这个方法来处理请求。
- @Path("/{username}")：这个注解指定了这个方法所处理的URL，其中{username}是一个占位符，表示一个变量，它将在运行时被实际的用户名所替换。例如，如果客户端访问的URL是http://example.com/hello/john，那么{username}将被替换为john。
- @Produces("text/plain;UTF-8")：这个注解指定了这个方法将返回的数据类型。在这个例子中，这个方法将返回一个纯文本的字符串，字符集为UTF-8。
- @PathParam("username")：这个注解将把URL中的{username}变量映射到方法的参数中，使得方法能够获取到客户端请求中的用户名。
669
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
