RESTful 面试题及详细答案（实战完整版）

RESTful面试题及详细答案（实战完整版）一、基础概念类1.什么是REST？什么是RESTful风格？答案：REST是表述性状态转移（RepresentationalStateTransfer）的缩写，是一种面向资源的软件架构风格，主要用于分布式网络系统的接口设计，最早用于规范网络服务的交互方式。RESTful就是遵循REST架构规范设计的接口风格，核心思想是把所有业务内容都抽象为「资源」，通过标准HTTP方法对资源进行增删改查，摒弃自定义接口请求方式，让接口统一、规范、可复用。简单来说：REST是架构准则，RESTful是落地的接口设计规范。2.RESTful核心设计原则有哪些？答案：日常开发中最核心、面试高频的5个原则：资源唯一标识：所有数据、业务实体都是资源，通过URL唯一标识，比如用户、订单、商品统一请求方法：使用HTTP标准方法定义操作，不自定义method无状态性：服务器不存储客户端状态，每次请求独立，请求必须携带全部必要参数、token等信息统一返回格式：通过HTTP状态码区分结果状态，响应数据格式统一（常用JSON）可缓存性：接口数据可根据场景设置缓存，提升访问效率3.REST接口为什么要求无状态？有什么优缺点？答案：无状态指：服务端不保存任何客户端的会话信息，每一次HTTP请求都是独立的，服务器不会记录上一次请求的内容和状态。优点：方便水平扩容，多台服务器部署时无需同步会话状态请求独立性强，出错重试、重试请求不会出现数据错乱服务器压力更小，无需维护会话缓存缺点：每次请求必须携带身份凭证（token），请求报文体积略微增大无法在服务端临时存储用户状态，部分场景需要额外缓存（Redis）配合二、HTTP方法与接口设计核心4.RESTful常用5种HTTP方法及对应场景？答案：请求方法作用幂等性常用场景GET查询资源幂等查询列表、查询详情，只读操作POST新增资源非幂等创建用户、创建订单、提交表单PUT全量更新资源幂等修改完整用户信息、完整替换资源数据PATCH局部更新资源幂等只修改用户名、只修改订单状态DELETE删除资源幂等删除单条数据、注销资源5.什么是幂等性？RESTful接口为什么需要保证幂等？答案：幂等性指：同一个请求执行一次和执行多次，最终服务器资源状态一致，不会产生副作用。比如GET、PUT、DELETE、PATCH都是幂等方法；POST默认非幂等，多次提交会重复创建数据。为什么需要幂等：网络请求经常出现超时、重试、前端重复点击、网关重试等情况，如果接口不幂等，会出现重复下单、重复修改、重复删除、数据错乱等线上问题。所以生产环境中，非幂等的POST接口必须手动做幂等处理。6.PUT和PATCH的核心区别？开发中怎么选择使用？答案：PUT：全量更新需要传入资源的完整字段，未传递的字段会被清空或覆盖，适用于整体替换资源的场景，具备幂等性。PATCH：局部更新只需要传入需要修改的字段，未传递的字段保持不变，适用于部分字段修改场景，具备幂等性。开发选择：日常90%的修改场景用PATCH，更灵活、安全性更高，不会误清空字段需要完整替换资源、重置全部数据时使用PUT三、URL设计规范（高频面试）7.RESTfulURL设计有哪些硬性规范？答案：这是面试和代码评审最常查的规范，核心规则：URL只写名词，不写动词资源名词统一使用复数层级资源用/拼接，通过路径区分父子资源过滤、分页、排序用query参数，不写在路径中全部小写，多个单词用下划线或中横线连接，禁止驼峰错误示例：/getUser、/addOrder、/updateUserInfo（带动词，不规范）正确示例：GET/users查询用户列表GET/users/1001查询id=1001的用户POST/users新增用户PATCH/users/1001修改用户信息DELETE/users/1001删除用户8.层级资源（关联资源）URL怎么设计？答案：父子关联资源，采用层级路径设计，清晰体现归属关系。示例：用户和用户订单的关联关系GET/users/1001/orders查询1001用户的所有订单GET/users/1001/orders/2001查询1001用户的2001号订单POST/users/1001/orders为该用户创建订单注意：多层资源不要超过3级，路径过长会降低可读性和维护性。四、状态码与返回格式9.RESTful常用HTTP状态码及使用场景？答案：开发中高频使用、面试必问的状态码：2xx成功200OK：普通查询、修改成功201Created：资源创建成功（POST新增接口专用）204NoContent：删除成功，无返回数据3xx重定向/缓存304NotModified：资源未更新，走本地缓存4xx客户端错误400BadRequest：参数错误、格式错误401Unauthorized：未登录、token失效403Forbidden：已登录，但无操作权限404NotFound：接口不存在、资源不存在405MethodNotAllowed：请求方法不支持（比如用GET请求新增接口）409Conflict：数据冲突、重复提交5xx服务端错误500InternalServerError：服务代码异常、数据库报错502BadGateway：网关/反向代理异常503ServiceUnavailable：服务宕机、过载、维护中10.RESTful接口返回数据格式怎么设计？答案：标准统一返回结构，不冗余、信息完整，适配前后端协作：code：业务自定义状态码（区分具体业务错误）message：提示信息（成功/错误文案）data：返回的业务数据，无数据时返回null标准示例：PlainText

{

"code":200,

"message":"操作成功",

"data":{

"id":1001,

"username":"test"

}

}注意：HTTP状态码用来给「网关、浏览器、框架」识别，自定义业务码用来给「前端业务判断」，二者配合使用。五、实战难点与踩坑（面试加分项）11.POST接口非幂等，生产环境如何解决重复提交问题？答案：实际开发中四种主流解决方案，按优先级排序：唯一幂等键：前端生成唯一订单号、请求ID，服务端根据唯一键做去重，重复请求直接返回成功数据库唯一索引：核心业务字段加唯一索引，重复插入直接报错拦截分布式锁：新增业务前加锁，同一业务请求只允许一次执行前端防抖/禁用按钮：辅助手段，只能解决用户手动重复点击，无法解决网络重试问题12.RESTful接口如何处理分页、排序、筛选？答案：绝对不要把分页、筛选参数写在URL路径中，统一使用query参数，规范清晰、可复用。标准示例：分页：GET/users?page=1&size=10排序：GET/users?sort=createTime&order=desc筛选：GET/users?status=1&gender=013.RESTful和RPC接口的区别？什么场景用REST？什么场景用RPC？答案：核心区别REST：基于HTTP协议，面向资源，通用性强、可读性高、调试简单，跨语言友好RPC：自定义协议（如gRPC、Dubbo），面向方法，传输体积小、速度快、效率高使用场景RESTful：前后端交互、第三方对外接口、开放API、跨系统通用调用RPC：微服务内部服务互相调用、高并发、高性能的内部接口场景14.RESTful接口常见设计错误有哪些？答案：URL中出现动词：/addUser、/deleteOrder，违背资源风格不区分PUT和PATCH，所有更新都用POSTGET请求传body参数（HTTP规范不推荐，部分网关会拦截）状态码滥用，所有成功统一返回200，所有错误统一返回500接口不做幂等处理，线上出现重复数据问题无状态设计不规范，服务端依赖会话存储用户状态六、进阶面试题15.如何实现RESTful接口的版本控制？答案：主流三种方案，生产最常用第一种：URL路径版本（推荐）：/v1/users、/v2/users，直观清晰、适配网关路由请求头版本：自定义header携带版本号，不污染URL参数版本：/users?version=1，简单但不美观，少用16.