API通过客户端发送请求（含参数、方法、头信息）至服务器，服务器解析后执行逻辑并返回响应（状态码、数据、头信息），基于HTTP/HTTPS协议传输，支持JSON/XML等格式，需处理
API 发送和接收详解
API 基础概念
| 概念 | 说明 |
|---|---|
| API（Application Programming Interface） | 应用程序编程接口，是不同软件之间进行交互的约定和规范，允许一个程序调用另一个程序的功能或数据。 |
| RESTful API | 基于 HTTP 协议的 API 设计风格，遵循资源导向、无状态等原则，常用于 Web 服务的构建。 |
| 请求（Request） | 客户端向服务器发起的数据交互请求，包含请求方法、URL、请求头和请求体等信息。 |
| 响应（Response） | 服务器对客户端请求的回复，包含状态码、响应头和响应体等内容。 |
API 请求的发送
（一）请求方法
| HTTP 方法 | 用途 |
|---|---|
| GET | 获取资源，通常用于从服务器读取数据，请求参数通过 URL 传递。 |
| POST | 创建资源，向服务器提交数据，如表单提交、文件上传等，数据放在请求体中。 |
| PUT | 更新资源，将客户端的数据完整替换服务器上的资源。 |
| DELETE | 删除资源，指定要删除的资源路径。 |
（二）参数传递
- 查询参数（Query Parameters）：附加在 URL 后面，以键值对形式出现，多个参数用“&”连接，
https://api.example.com/users?name=John&age=30。 - 路径参数（Path Parameters）：直接嵌入在 URL 路径中，用于标识特定资源，
https://api.example.com/users/123，123”可能是用户 ID。 - 请求体参数（Body Parameters）：主要用于 POST、PUT 等方法，携带复杂的数据结构，如 JSON、XML 或表单数据。
（三）请求头设置
| 常用请求头 | 作用 |
|---|---|
| Content-Type | 指定请求体的数据类型，如 application/json 表示 JSON 格式数据。 |
| Authorization | 用于身份验证，如 Bearer Token 认证。 |
| User-Agent | 标识客户端应用程序的类型和版本。 |
| Cookie | 携带服务器返回的会话信息，用于保持登录状态等。 |
（四）错误处理
- 网络错误：如超时、连接中断等,需进行重试机制或提示用户检查网络。
- HTTP 错误状态码：如 400（客户端请求错误）、401（未授权）、403（禁止访问）、404（资源未找到）、500（服务器内部错误）等，根据状态码采取相应措施，如提示用户修改请求、重新登录或联系服务器管理员。
API 响应的接收
（一）响应状态码
| 状态码类别 | 含义 | 常见状态码 |
|---|---|---|
| 1xx | 信息响应，表示请求已接收，继续处理。 | 100（继续）、101（切换协议） |
| 2xx | 成功，请求已成功被服务器处理。 | 200（OK）、201（已创建）、204（无内容） |
| 3xx | 重定向，需要客户端进一步操作以完成请求。 | 301（永久移动）、302（临时移动）、304（未修改） |
| 4xx | 客户端错误，请求包含错误或无法被服务器处理。 | 400（错误请求）、401（未授权）、403（禁止访问）、404（资源未找到） |
| 5xx | 服务器错误，服务器在处理请求时发生错误。 | 500（内部服务器错误）、502（错误网关）、503（服务不可用） |
（二）响应体解析
- JSON 格式：最常见的响应数据格式，可通过编程语言的 JSON 解析库将其转换为对象或字典进行数据处理，例如在 JavaScript 中使用
JSON.parse()，在 Python 中使用json.loads()。 - XML 格式：相对较少使用，但一些传统系统或特定领域可能采用，需要使用相应的 XML 解析库进行处理。
- 文本格式：简单的纯文本数据,直接读取即可。
（三）错误处理
- 业务逻辑错误：根据响应体中的错误信息，如错误代码、错误消息等，在客户端进行相应的提示和处理,引导用户正确操作或提供解决方案。
- 数据格式错误：如果响应数据格式不符合预期，可能是服务器端问题或数据传输过程中出错，需要进行日志记录和排查,必要时与服务器端开发人员沟通协调解决。
（四）超时处理
- 设置合理的请求超时时间，避免客户端长时间等待无响应的请求，若超时，可进行重试或提示用户网络状况不佳,稍后重试。
相关问题与解答
问题 1：如何在 API 请求中传递敏感信息，如用户密码？
解答：一般不建议直接在请求中明文传递敏感信息，对于用户密码等敏感数据,通常采用以下方式处理：
- 加密传输：使用 HTTPS 协议，对整个请求进行加密，防止数据在网络传输过程中被窃取或篡改，在 HTTPS 连接中，数据在客户端和服务器之间是加密传输的，即使被拦截,也无法轻易获取明文内容。
- 哈希处理：在客户端对密码进行哈希计算（如使用 SHA-256 等算法），然后将哈希值传递给服务器，服务器端存储的也是密码的哈希值，在验证用户登录时，将客户端传来的哈希值与服务器端存储的哈希值进行比对，从而避免直接存储和传输明文密码，不过需要注意的是，哈希算法应选择安全的、不易被破解的算法，并且可以结合加盐（Salt）技术，增加密码破解的难度，在注册时为用户生成一个随机的 Salt 值，并将 Salt 值与密码一起哈希后存储，在登录验证时，使用相同的 Salt 值对用户输入的密码进行哈希,再与存储的哈希值进行比对。
问题 2：当 API 响应数据量较大时，如何优化客户端的性能？
解答：当面对大量 API 响应数据时,可以采取以下优化措施来提高客户端性能：
- 分页加载：对于列表数据等可分页的内容，采用分页请求的方式，每次只获取一部分数据进行显示和处理，每页显示 20 条数据，当用户滚动到页面底部时，再加载下一页数据，这样可以减少一次性加载的数据量,降低内存占用和网络传输时间。
- 数据缓存：在客户端对已经获取过的数据进行缓存，当再次需要相同数据时，直接从缓存中读取，而不需要再次发送 API 请求，可以使用浏览器的本地存储（如 LocalStorage、SessionStorage）或内存缓存（如 JavaScript 对象）来存储数据，但需要注意缓存的有效期和更新机制,以确保数据的时效性。
- 数据压缩：如果服务器支持，可以在请求头中设置
Accept-Encoding为gzip等压缩格式，让服务器对响应数据进行压缩后再传输，客户端在接收到压缩数据后，再进行解压缩处理，这样可以减小数据传输的大小，提高传输速度,但会增加一定的计算开销用于压缩和解压缩操作。 - 异步加载和渲染：利用异步编程技术（如 JavaScript 的 Promise、async/await），在后台异步获取 API 数据，不阻塞主线程的执行，当数据获取完成后，再更新页面的显示内容，这样可以提高页面的响应速度，让用户在等待数据加载的过程中可以继续与页面进行其他交互操作，在页面加载时先显示一个加载动画，然后在后台异步获取数据并更新页面内容，当数据加载完成后，隐藏加载动画并
到此，以上就是小编对于“api 发送和接收”的问题就介绍到这了，希望介绍的几点解答对大家有用，有任何问题和不懂的，欢迎各位朋友在评论区讨论，给我留言。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复