http/https系列(一)

协议介绍

HTTP（Hypertext Transfer Protocol:超文本传输协议）是一种应用层协议，用于从Web服务器传输超文本信息（如HTML页面）到客户端浏览器。 它是互联网上应用最广泛的网络协议，基于TCP/IP协议，默认端口号为80。HTTP协议是无状态的，意味着服务器不保留之前请求的信息，每个请求都是独立的。

HTTPS（Hypertext Transfer Protocol Secure:超文本传输安全协议）是在HTTP的基础上发展起来的，通过添加SSL/TLS（Secure Sockets Layer/Transport Layer Security）协议层，为数据传输提供了安全性的增强版本。
HTTPS的主要目的是提供加密和身份验证，确保数据在传输过程中的完整性和保护用户隐私。默认端口号为443。
使用HTTPS时，客户端和服务器之间的通信会被加密，防止数据被第三方窃取或篡改，常用于涉及敏感信息传输的场景，如在线交易、银行服务和登录凭证交换等。

请求方式

GET 请求:

• 目的：主要用于请求服务器发送已标识的资源。这意味着GET请求是用来从服务器检索信息的，比如获取网页内容、图片或者任何其他类型的数据。
• 参数传递：GET请求会把请求参数附加在URL后面，以查询字符串(query)的形式出现，例如 www.example.com/data?param1=value1&param2=value2。 由于参数直接可见于URL中，因此不适合传输敏感信息。
• 幂等性：GET请求是幂等的，即对同一URL的多个请求应该产生相同的结果，不会因多次请求而改变服务器状态。
• 缓存：GET请求可以被浏览器缓存，这有助于提高性能，但也可能导致隐私或安全问题。
• 长度限制：虽然HTTP协议本身没有规定GET请求的长度限制，但实际上URL的长度受限于浏览器和服务器，通常建议不要超过2048个字符。

POST 请求:

• 目的：主要用于向服务器提交数据，以便在服务器上创建或更新资源。常用于表单提交、文件上传等场景。
• 参数传递：POST请求将请求参数放在请求正文中，而不是URL中，因此可以传输大量数据，并且对用户而言是不可见的，提高了安全性。
• 幂等性：POST请求不是幂等的，多次请求可能会导致服务器上创建多个资源或产生不同的副作用。
• 缓存：默认情况下，POST请求不会被浏览器缓存，但可以通过设置特定的HTTP头部来改变这一行为。

除了GET和POST之外，HTTP/HTTPS协议还定义了其他几种请求方法，尽管它们在特定场景下非常有用，但在日常的web开发和交互中并不像GET和POST那样频繁使用。
在restful风格的api中，会使用到：

• PUT: 用于替换服务器上的现有资源或在指定URI下创建新资源。相比POST，PUT强调的是幂等性
• DELETE: 用于请求服务器删除指定的资源。
• PATCH: 用于对资源进行部分更新。相比于PUT的完全替换，PATCH提供了更细粒度的修改能力。
• …

传输数据的方式

• 查询字符串（Query String）：
  这是最常见的参数传递方式之一，适用于GET请求。参数以键值对的形式附加在URL后面，使用问号（?）分隔URL和参数，多个参数之间使用&符号分隔。例如：https://example.com/api/data?key1=value1&key2=value2。 这种方式适合传递非敏感信息，因为参数直接可见于URL中。
• 请求体（Request Body）：
  通常用于POST、PUT、PATCH等请求方法中，参数放在HTTP请求的消息体中。根据Content-Type的不同，请求体可以是多种形式，如表单形式（application/x-www-form-urlencoded）、JSON（application/json）、XML等。这种方式适合传输大量数据或敏感信息，因为数据不在URL中显示，相对更安全。
• 路由参数（Route Parameters 或 Path Parameters）：
  当使用RESTful风格的API时，参数可以直接嵌入到URL的路径中，如https://example.com/users/{userId}，这里的{userId}就是一个路由参数。这种方式适用于标识资源，服务器可以根据路径中的参数直接定位资源。
• 请求头（Request Headers）：
  虽不常见于传输主要业务数据，但某些认证信息（如API密钥、Token）或特定的指令可通过请求头传递。例如，Authorization头常用于携带认证信息。

几种常见的请求体传参

• application/x-www-form-urlencoded:
  这是最常见的形式，类似于查询字符串的格式，键值对以key=value形式，多个键值对之间用&连接，且都进行了URL编码(url)。例如，表单提交时默认使用此格式。在请求体中看起来像这样：key1=value1&key2=value2。
• multipart/form-data:
  用于上传文件或需要二进制数据的场景。它将请求分割成多个部分，每一部分可以有自己的Content-Type，并且支持大文件和非文本内容。这种格式常用于文件上传表单。
• application/json:
  当前Web服务中最流行的格式之一，用于传输JSON对象。数据以JSON格式编码，易于人阅读和机器解析。例如：{“key1”: “value1”, “key2”: “value2”}。适用于RESTful API，特别是当数据结构较复杂时。
• text/xml 或 application/xml:
  早期Web服务中常用，数据以XML文档形式组织。虽然现在不如JSON流行，但在某些特定领域或遗留系统中仍有使用。示例：

<root><key1>value1</key1><key2>value2</key2></root>

• 纯文本（text/plain）:
  简单的文本内容，没有特定的结构，适合传输纯文本消息。例如，发送一个简单的消息或日志内容。

url编码(url encode)

在使用application/x-www-form-urlencoded格式传递请求体参数时，参数的值需要经过一个特殊的过程转换，称为URL编码（也称为百分号编码）。这个过程是为了确保数据能够安全地通过网络传输，避免引起解析错误或安全问题。
URL编码主要是对某些字符进行替换：
空格被替换为加号（+）或 %20。
非字母数字字符（如中文字符、符号等）被转换为”%HH”的形式，其中HH是该字符的两位十六进制表示。
例如，如果原始数据中有空格、中文或其他特殊字符，就需要进行这样的转换：

空格 “ “ 变成 “+” 或 “%20”
中文字符”你好”变成”%E4%BD%A0%E5%A5%BD”
这样做的目的有两个：

• 保证传输安全：确保特殊字符不会被误解，比如 &、= 这些字符在URL中有特殊意义，如果不编码，可能会干扰到参数的正确解析。
• 兼容性：历史原因，早期的网络协议和系统对非ASCII字符支持有限，URL编码保证了所有数据都能以ASCII字符集安全传输。
  所以，当提到请求体参数或查询字符串中的数据“都进行了URL编码”，意味着数据已经过这样的转换处理，以确保在网络中能够正确无误地传输和解析。