首页   注册   登录
iugo

iugo

各行其是.
V2EX 第 1150 号会员,加入于 2010-08-21 00:21:10 +08:00
v2ex at iugo.dev

8FDE55864EBA

不喜欢规矩, 但同样不喜欢破坏规矩.

喜欢简单的东西, 迫切希望得到一个简单的逻辑解决大多数问题.

比较宽容. 不会讳疾忌医. 喜欢了解各方各种观点看法.

曾是私立学校教师.
曾是书店收银员.
曾是工厂家具雕刻设计员、工人.
曾是建筑工地走水电工人.
曾是公司职员.
曾是一年支教志愿者.
根据 iugo 的设置,主题列表只有在你登录之后才可查看
iugo 最近回复了
个人经历: 使用 Mac 后, 不再用鼠标.

用 Windows 的时候, 还是保留了使用触摸板的习惯, 但不适应, 几乎没在用 Windows 了.

但任何东西都是可以回去的, 如果现在硬要我用回鼠标, 相信经过一段时间适应也没问题.
21 天前
回复了 felix021 创建的主题 程序员 踩坑记: Go 服务灵异 panic
在 Go 入门中曾明确写 SliceHeader 的三部分, 但没有提 StringHeader.

不说深究 Go 的运行时了, 把所有官方包好好看看就足够对 Go 提升认识了. (当然还要有空翻翻标准)
23 天前
回复了 Vimax 创建的主题 Java RESTful 的增删改查成功应该返回什么状态码?
虽然对于这种人造的, 有历史的东西, 争论没有意义. 但我觉得在这个过程中, 我们能对什么是更好的有更多的理解. 我们的讨论都是在表述自己的理解, 不存在说服谁的问题.

以下都是我的想法, 不是客观正确的, 是我认为正确的. 不是要说服谁, 是想表达让大家参考, 也期待大家有相关的分享让我参考. 讨论的目的只是互通有无.

## 关于是否使用 REST

首先, 如果不用 REST, 进入业务后都返回 200 是一种我可以接受的设计. 这点我觉得没有问题. 我的个人经验是, 交互业务重时, REST 捉襟见肘.

## 关于什么是 HTTP Client

但当我作为前端时, 我可能更希望大家去使用 HTTP 状态码而不是不去用. 因为我这个前端不认为 4xx 错误码是给前端代码用的, 而是给用户的. Client 可能表示前端代码, 浏览器, 用户. 前端也是 user agent, 和浏览器一样, client 应该主要代表 user, 而不是 user agent.

## 是否要用 HTTP 状态码

基于与 HTTP Client 的想法, 所以我倾向于 API 使用更多的 HTTP 状态码.

## 关于 REST 最初设计的想法 (暂存草稿)

https://v2ex.com/t/689938?p=1#r_9251862

> The key abstraction of information in REST is a resource.

- HTTP 协议有状态码设计.

> Although those implementations reflect many of the design constraints of REST, having been developed by people familiar with the Web's architectural design and rationale, the real WWW architecture is independent of any single implementation. The modern Web is defined by its standard interfaces and protocols, not how those interfaces and protocols are implemented in a given piece of software.

- REST 存在一些设计约束, 这些设计约束来源于当时的 WWW 实现(比如 libwww, 在现在我已经不知道这是个什么东西了, 应该类似于 HTTP 服务端与浏览器的结合吧).
- WWW 是独立的, 不受制于任何软件设计实现, REST 也是一种利用 WWW 实现业务的设计实现, 不应该被排除, 大家可以考虑考虑.
24 天前
回复了 Vimax 创建的主题 Java RESTful 的增删改查成功应该返回什么状态码?
不是说 REST 多好多好, 大家都该用.

而是主题问的是 REST, 所以就这个来回答不跑题.

1. REST 到底好不好用, 这个见仁见智, 但较为老旧简单难以适应复杂需求这点可能更多人认同.
2. HTTP 状态码到底怎么用, 我认为还是要看情况吧, 所有业务一旦进入处理流程都 200 太绝对了.
24 天前
回复了 Vimax 创建的主题 Java RESTful 的增删改查成功应该返回什么状态码?
@libook

不是纠结一定要 REST, 而是认为 HTTP 状态码在一些地方应该被使用.

Web 最初是为了描述网页资源.

如果一个文章网页曾经存在, 但因为一些原因被删除了.

客户端是浏览器.

这时后端返回 404 是不是更好一些?

---

再说 API.

如果请求 `GET /item?id=123`, 数据库中没这一数据, 这时候状态返回 200, 再给数据不存在的业务代码是合理的.

但是如果请求 `GET /item/123`, 数据库中没这一数据, 我认为这时候状态返回 404 而不是 200 才是合适的.

具体用哪种风格好, 我不评论. 只是主题说了 "RESTful 的增删改查成功应该返回什么状态码?", 而不是 "API 的增删改查成功应该返回什么状态码?", 所以主题说的应该是上例中的后者.
24 天前
回复了 Vimax 创建的主题 Java RESTful 的增删改查成功应该返回什么状态码?
如果把 HTTP 状态码当作后端错误代码的分类, 这样似乎就很好理解.

我是不建议弃用 HTTP 状态码, 只用 200 的.
24 天前
回复了 Vimax 创建的主题 Java RESTful 的增删改查成功应该返回什么状态码?
@libook

- 需要告诉客户端它犯了个(请求的资源不存在的)错误
- 这个资源不存在

我觉得这两个难以区分.

我认为我理解你想要表达的, 就是协议统统 200, 不需要 404, 除非 API 路由都不对, 才会 404.

但这种设计不符合 RESTful, 这里不是说 RESTful 绝对正确, 而是不符合 RESTful.
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2137 人在线   最高记录 5168   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 11ms · UTC 01:56 · PVG 09:56 · LAX 18:56 · JFK 21:56
♥ Do have faith in what you're doing.