北京
周二下午，隔壁工位的后端老哥盯着终端里一行403 Forbidden直嘬牙花子，嘴里嘟囔着“我明明登录了啊”。我瞄了一眼他塞在请求体里的Bearer Token，差点把咖啡喷在机械键盘上——兄弟，你把门禁卡扔在快递盒子里，门卫当然不放你进啊。
我们每天在浏览器里点点点，每一个页面背后都是一场严格遵循剧本的送货大戏。今天就用拆快递的方式，把这套叫HTTP的数据交换协议拆开看看，保你以后不再对着状态码抓瞎。
一来一回的铁律：请求永远只配得到一个响应。客户端先通过TCP三次握手（默认走443端口）跟服务器拉上线，然后扔过去一个格式化的请求块——“我要拿什么、我是谁、我接受什么格式”。服务器解析后埋头处理，最终丢回一个格式化的响应块，顺带附上结果。这一趟跑完，连接要么关闭，要么复用着等下一次。别小看这个循环，所有App、网站都在这个圈里打转。
四个Header像快递单上的备注栏，少填一个就翻车。User-Agent告诉服务器你用的什么浏览器，Authorization塞着你的身份凭证（比如Bearer Token），Content-Type声明你寄来的包裹里装的到底是JSON、XML还是纯文本，Set-Cookie则从服务器那边递过来一张小纸条，让你下次别再自报家门。忘了写Content-Type，服务器可能直接当你寄了一坨废纸。
状态码速查：别再跟我扯401和403的区别。200 OK是“快递签收成功”，201 Created是“新订单已创建”。300系列代表“收货地址换了，自己查新地址去”。400开头全是客户端的锅：400 Bad Request是你包裹单乱填，401 Unauthorized是你没带身份证还硬闯，403 Forbidden是你带了身份证但没权限进这个门——很多人的bug就卡在这一步。最后500 Internal Server Error是“仓库炸了，改天再来”。
URL像地图上的路线：斜杠后面是门牌号，问号后面是附加要求。https://api.rextora.com/users/42?active=true&sort=desc来说，/users/42里的42是路径参数，拍板要查那个唯一ID的用户；而?active=true&sort=desc是查询参数，不换底层的门牌，只是要求“只返回活跃用户，按倒序排列”。至于真正要传的大块数据（新增用户信息、一整个订单的JSON），别塞在URL里，请放进请求体。
HTTP天生健忘，Cookie和Session是补上的便签纸。协议本身每处理完一次请求就翻脸不认人，这是它的无状态特性。为了让你连续操作时不至于每刷新一下页面就被踢出登录，服务器会给一个Set-Cookie，浏览器再傻乎乎地每次请求都带回来；后台则靠Session记录你的登录状态。认证是验明正身，授权是规定你能干啥——登录时贴的是认证标签，改管理员设置时才查授权，别把两件事混成一锅粥。最后，REST API用JSON、XML或YAML这类序列化格式统一打包数据，保证不同语言写的服务都能顺畅拆箱验货。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
