a*8
2 楼
给TSC transfer到其他处理中心了，我还以为这么快就批了。
有没有人给transfer过？是不是说明TSC积压的485太多了？
有没有人给transfer过？是不是说明TSC积压的485太多了？
y*8
3 楼
CUTE吧？希望同学们和我一样喜欢。在动物园拍到的，不是高清的，凑合看。
为新斑竹上任第一天加油凑一个贴;同时安慰东部受灾农民：祈望飓风快点PASS，各家
菜园花圃损失甚微，最好安然无恙虚惊一场。
为新斑竹上任第一天加油凑一个贴;同时安慰东部受灾农民：祈望飓风快点PASS，各家
菜园花圃损失甚微，最好安然无恙虚惊一场。
s*n
4 楼
中午12点左右还有的，
结果又是运费有时会员费的，
一犹豫就飞了
尼玛的hp，今天全美都在为这疯狂啊
结果又是运费有时会员费的，
一犹豫就飞了
尼玛的hp，今天全美都在为这疯狂啊
g*t
5 楼
对同一个resource,例如一张表，有7个actions,例如查询，
分组，等7个类似于sql那种要求。
那么该怎么设计API endooints什么的？
我的做法是：
全用POST method, 不理会GET POST PUT...这套。
POST上传actions的参数，7个API的名字包含在URL里。
这样做优劣如何？请大家批评指正。
分组，等7个类似于sql那种要求。
那么该怎么设计API endooints什么的？
我的做法是：
全用POST method, 不理会GET POST PUT...这套。
POST上传actions的参数，7个API的名字包含在URL里。
这样做优劣如何？请大家批评指正。
l*n
6 楼
不要
你已经有了电子版在160里面了
我父母2号签的
你已经有了电子版在160里面了
我父母2号签的
a*x
7 楼
都怪talented
【在 a*******8 的大作中提到】
: 给TSC transfer到其他处理中心了，我还以为这么快就批了。
: 有没有人给transfer过？是不是说明TSC积压的485太多了？
【在 a*******8 的大作中提到】
: 给TSC transfer到其他处理中心了，我还以为这么快就批了。
: 有没有人给transfer过？是不是说明TSC积压的485太多了？
i*t
8 楼
cute!
怎么感觉熊猫在山顶上？
不怕掉下去？
怎么感觉熊猫在山顶上？
不怕掉下去？
s*e
9 楼
根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“GET”对
应的那部分。
使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
Restful 不太完备。主要的限制是：
1. HTTP 里的 GET 是有长度限制的
目前主流产品（apache，tomcat，jetty，haproxy等）的默认长度是8K-16K，如果是代
理，像haproxy，实际使用内存翻倍，因为它需要 URL rewrite。这个长度是HTTP头和
URL共享的，如果头部（cookie，host info，auth等）内容太多，URL的长度会进一步
受限。如果你的查询API非常复杂，那么使用GET就会碰到长度限制问题。
2. 标准协议不支持 GET + RequestBody
目前用过方式的有以下几种，碰到的问题和优缺点罗列一下：
1. 使用常规GET+Query Parameter
Pro：符合http 和 restful规范
Con：长度限制，测试用例比较复杂，需要URLencode特殊数据，客户端需要构建查询
URL，服务器端需要逐个解析参数
2. 使用GET + urlencode（JSON）
比如：/user?query={"name"="zhang*","address"="60 abc*"}
Pro：符合http 和 restful规范，查询请求可以在两端同构：查询参数在前后端以对象
形式存在，可以一步转换并构建查询URL，后端也可以一步解析转换成查询请求对象
Con：长度限制，需要URLEncode
3. 使用 POST + RequestBody，就是楼主提到的方法
Pro：没有URL长度限制，（实际还是有的，受服务器端 max upload，即RequestBody
长度限制），两端的代码可以非常简单，查询对象在两端同构
Con：不符合Restful规范，如果你有SOA中间件，不符合规范，或许会造成一些小小的
困扰，对有API洁癖的人造成心理阴影
4. 使用GET + RequestBody。这个方法被 ElasticSearch 大量使用
其基本原理是，很多服务器的HTTP GET实现，实际是允许有 RequestBody 的：发送
GET 请求，可以和POST一样，查询请求对象放在RequestBody里
Pro：优点同 POST + RequestBody
Con：不符合标准的 HTTP 协议，服务器、中间件或代理可能不支持这种方式，很多客
户端不支持，测试不太方便，其他缺点同POST+RequestBody
很难说那种方式合适，还是要看具体情况
应的那部分。
使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
Restful 不太完备。主要的限制是：
1. HTTP 里的 GET 是有长度限制的
目前主流产品（apache，tomcat，jetty，haproxy等）的默认长度是8K-16K，如果是代
理，像haproxy，实际使用内存翻倍，因为它需要 URL rewrite。这个长度是HTTP头和
URL共享的，如果头部（cookie，host info，auth等）内容太多，URL的长度会进一步
受限。如果你的查询API非常复杂，那么使用GET就会碰到长度限制问题。
2. 标准协议不支持 GET + RequestBody
目前用过方式的有以下几种，碰到的问题和优缺点罗列一下：
1. 使用常规GET+Query Parameter
Pro：符合http 和 restful规范
Con：长度限制，测试用例比较复杂，需要URLencode特殊数据，客户端需要构建查询
URL，服务器端需要逐个解析参数
2. 使用GET + urlencode（JSON）
比如：/user?query={"name"="zhang*","address"="60 abc*"}
Pro：符合http 和 restful规范，查询请求可以在两端同构：查询参数在前后端以对象
形式存在，可以一步转换并构建查询URL，后端也可以一步解析转换成查询请求对象
Con：长度限制，需要URLEncode
3. 使用 POST + RequestBody，就是楼主提到的方法
Pro：没有URL长度限制，（实际还是有的，受服务器端 max upload，即RequestBody
长度限制），两端的代码可以非常简单，查询对象在两端同构
Con：不符合Restful规范，如果你有SOA中间件，不符合规范，或许会造成一些小小的
困扰，对有API洁癖的人造成心理阴影
4. 使用GET + RequestBody。这个方法被 ElasticSearch 大量使用
其基本原理是，很多服务器的HTTP GET实现，实际是允许有 RequestBody 的：发送
GET 请求，可以和POST一样，查询请求对象放在RequestBody里
Pro：优点同 POST + RequestBody
Con：不符合标准的 HTTP 协议，服务器、中间件或代理可能不支持这种方式，很多客
户端不支持，测试不太方便，其他缺点同POST+RequestBody
很难说那种方式合适，还是要看具体情况
n*m
10 楼
谢谢！
J*1
11 楼
My RD is Nov.7. I didn't recieve anything from USCIS then. Does figure
printing notce send to lawyer office or to applicant? Thank you.
【在 a*******8 的大作中提到】
: 给TSC transfer到其他处理中心了，我还以为这么快就批了。
: 有没有人给transfer过？是不是说明TSC积压的485太多了？
printing notce send to lawyer office or to applicant? Thank you.
【在 a*******8 的大作中提到】
: 给TSC transfer到其他处理中心了，我还以为这么快就批了。
: 有没有人给transfer过？是不是说明TSC积压的485太多了？
y*8
12 楼
是动物园的装饰背景。
宝贝着呢，哪能让他们摔着！
【在 i****t 的大作中提到】
: cute!
: 怎么感觉熊猫在山顶上？
: 不怕掉下去？
宝贝着呢，哪能让他们摔着！
【在 i****t 的大作中提到】
: cute!
: 怎么感觉熊猫在山顶上？
: 不怕掉下去？
s*e
13 楼
补充一下，HTTP 请求的长度限制是可以通过配置修改的，但是一般不建议：
1. 首先修改比较麻烦，而且需要修改整个请求链里的全部节点
2. 这个buffer是服务器高频分配使用的，对性能有严重的影响。越长的buffer，意味
着需要更多的内存支持同样数量的并发请求。另外，长度越长，处理时间越长，单个请
求延迟会增加，最终会影响整体性能。
1. 首先修改比较麻烦，而且需要修改整个请求链里的全部节点
2. 这个buffer是服务器高频分配使用的，对性能有严重的影响。越长的buffer，意味
着需要更多的内存支持同样数量的并发请求。另外，长度越长，处理时间越长，单个请
求延迟会增加，最终会影响整体性能。
h*h
14 楼
各个地方不一样，我在南京，我们这边要带照片
【在 n******m 的大作中提到】
: 现在面签究竟要不要带照片？
: 有没有最近面签的同学说一下情况
: 谢谢
【在 n******m 的大作中提到】
: 现在面签究竟要不要带照片？
: 有没有最近面签的同学说一下情况
: 谢谢
w*2
15 楼
Both
h*s
16 楼
好可爱啊。
g*t
17 楼
非常感谢你的详细解释。
我说7个APi的时候脑子里有delete update 等actions,可能没说清楚。
1.
我现在的办法是能用post就用post. 按你前面第三条说的，
似乎缺点就是别的程序员主管不易接受。从时间空间强壮性的角度来看，似乎问题不大
？就是说各种服务器都没支持问题，目测5年后服务器软件改版本了，post也不会改掉。
2.
修改服务器配置这我觉得很难接受。
Http server政策制定者是高端人口。说不定哪天
版本更新，哪个配置就不管用了。
还是http post强壮些。
http get 加上request body回头我看下。
: 补充一下，HTTP 请求的长度限制是可以通过配置修改的，但是一般不建
议：
: 1. 首先修改比较麻烦，而且需要修改整个请求链里的全部节点
: 2. 这个buffer是服务器高频分配使用的，对性能有严重的影响。越长的
buffer
，意味
: 着需要更多的内存支持同样数量的并发请求。另外，长度越长，处理时间
越长，
单个请
: 求延迟会增加，最终会影响整体性能。
【在 s******e 的大作中提到】
: 补充一下，HTTP 请求的长度限制是可以通过配置修改的，但是一般不建议：
: 1. 首先修改比较麻烦，而且需要修改整个请求链里的全部节点
: 2. 这个buffer是服务器高频分配使用的，对性能有严重的影响。越长的buffer，意味
: 着需要更多的内存支持同样数量的并发请求。另外，长度越长，处理时间越长，单个请
: 求延迟会增加，最终会影响整体性能。
我说7个APi的时候脑子里有delete update 等actions,可能没说清楚。
1.
我现在的办法是能用post就用post. 按你前面第三条说的，
似乎缺点就是别的程序员主管不易接受。从时间空间强壮性的角度来看，似乎问题不大
？就是说各种服务器都没支持问题，目测5年后服务器软件改版本了，post也不会改掉。
2.
修改服务器配置这我觉得很难接受。
Http server政策制定者是高端人口。说不定哪天
版本更新，哪个配置就不管用了。
还是http post强壮些。
http get 加上request body回头我看下。
: 补充一下，HTTP 请求的长度限制是可以通过配置修改的，但是一般不建
议：
: 1. 首先修改比较麻烦，而且需要修改整个请求链里的全部节点
: 2. 这个buffer是服务器高频分配使用的，对性能有严重的影响。越长的
buffer
，意味
: 着需要更多的内存支持同样数量的并发请求。另外，长度越长，处理时间
越长，
单个请
: 求延迟会增加，最终会影响整体性能。
【在 s******e 的大作中提到】
: 补充一下，HTTP 请求的长度限制是可以通过配置修改的，但是一般不建议：
: 1. 首先修改比较麻烦，而且需要修改整个请求链里的全部节点
: 2. 这个buffer是服务器高频分配使用的，对性能有严重的影响。越长的buffer，意味
: 着需要更多的内存支持同样数量的并发请求。另外，长度越长，处理时间越长，单个请
: 求延迟会增加，最终会影响整体性能。
x*x
18 楼
南京是代签吧。中信银行的土规矩多而且不一致。面签一般不要照片。
【在 h**h 的大作中提到】
: 各个地方不一样，我在南京，我们这边要带照片
【在 h**h 的大作中提到】
: 各个地方不一样，我在南京，我们这边要带照片
U*S
19 楼
Which center has it been transferred to? I'm curious.NSC? CSC? VSC? Wondered
what's your RD?
what's your RD?
k*s
20 楼
小的更可爱
g*t
21 楼
你这个贴太好了。需要一看再看.
第二条是不是还有个缺点，就是URLencode别人能看见？
我一般干这活都是能不让人看见的都不让人看见。
: 根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“
GET”对
: 应的那部分。
: 使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
: Restful 不太完备。主要的限制是：
: 1. HTTP 里的 GET 是有长度限制的
: 目前主流产品（apache，tomcat，jetty，haproxy等）的默认长度是8K-16K，如
果是代
: 理，像haproxy，实际使用内存翻倍，因为它需要 URL rewrite。这个长度是
HTTP头和
: URL共享的，如果头部（cookie，host info，auth等）内容太多，URL的长度会
进一步
: 受限。如果你的查询API非常复杂，那么使用GET就会碰到长度限制问题。
: 2. 标准协议不支持 GET RequestBody
【在 s******e 的大作中提到】
: 补充一下，HTTP 请求的长度限制是可以通过配置修改的，但是一般不建议：
: 1. 首先修改比较麻烦，而且需要修改整个请求链里的全部节点
: 2. 这个buffer是服务器高频分配使用的，对性能有严重的影响。越长的buffer，意味
: 着需要更多的内存支持同样数量的并发请求。另外，长度越长，处理时间越长，单个请
: 求延迟会增加，最终会影响整体性能。
第二条是不是还有个缺点，就是URLencode别人能看见？
我一般干这活都是能不让人看见的都不让人看见。
: 根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“
GET”对
: 应的那部分。
: 使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
: Restful 不太完备。主要的限制是：
: 1. HTTP 里的 GET 是有长度限制的
: 目前主流产品（apache，tomcat，jetty，haproxy等）的默认长度是8K-16K，如
果是代
: 理，像haproxy，实际使用内存翻倍，因为它需要 URL rewrite。这个长度是
HTTP头和
: URL共享的，如果头部（cookie，host info，auth等）内容太多，URL的长度会
进一步
: 受限。如果你的查询API非常复杂，那么使用GET就会碰到长度限制问题。
: 2. 标准协议不支持 GET RequestBody
【在 s******e 的大作中提到】
: 补充一下，HTTP 请求的长度限制是可以通过配置修改的，但是一般不建议：
: 1. 首先修改比较麻烦，而且需要修改整个请求链里的全部节点
: 2. 这个buffer是服务器高频分配使用的，对性能有严重的影响。越长的buffer，意味
: 着需要更多的内存支持同样数量的并发请求。另外，长度越长，处理时间越长，单个请
: 求延迟会增加，最终会影响整体性能。
s*e
22 楼
1. 如果有增删改，还是建议遵守Restful规范，我使用了很长时间，有些API相当复杂
，在增删改部分，Restful 规范还是相当合用。我只在查询这块遇到过问题。规范的目
的主要是让团队、合作者、上下游的客户能够方便的理解和使用API。
2. 关于URL的安全问题：如果的你API是给其他应用的，不会在浏览器里使用，其他人
是无法直接用“肉眼”看到的。在传输过程中，安全问题可以通过HTTPS解决，当然你
可以自己加密。如果API在浏览器里大量使用（比如通过AJAX），那么是很容易被前端
工具截取的。
3. 关于URL关键内容加密，这里有个方案，或许对你有帮助。因为一些原因，我曾经开
发过一些加密过的API，主要是增加破解者通过API抓取和分析数据的难度。基本方式是
，对所有的document id进行有时间戳的加密。基本方式是：
encrypted-doc-id=encrypt(server-secret, doc-id, timestamp, random-string)+
random-string
random-string 做salt用
前端或友商获取到数据后，必须在规定时间内使用加密过的doc-id从服务器获相关数据
。单个客户的IP，单位时间内的请求数是受限的。
，在增删改部分，Restful 规范还是相当合用。我只在查询这块遇到过问题。规范的目
的主要是让团队、合作者、上下游的客户能够方便的理解和使用API。
2. 关于URL的安全问题：如果的你API是给其他应用的，不会在浏览器里使用，其他人
是无法直接用“肉眼”看到的。在传输过程中，安全问题可以通过HTTPS解决，当然你
可以自己加密。如果API在浏览器里大量使用（比如通过AJAX），那么是很容易被前端
工具截取的。
3. 关于URL关键内容加密，这里有个方案，或许对你有帮助。因为一些原因，我曾经开
发过一些加密过的API，主要是增加破解者通过API抓取和分析数据的难度。基本方式是
，对所有的document id进行有时间戳的加密。基本方式是：
encrypted-doc-id=encrypt(server-secret, doc-id, timestamp, random-string)+
random-string
random-string 做salt用
前端或友商获取到数据后，必须在规定时间内使用加密过的doc-id从服务器获相关数据
。单个客户的IP，单位时间内的请求数是受限的。
g*t
23 楼
我读了下Microsoft 的规范，规范确实有自己的道理。
里面有一小段话我想反着讨论下:
In 2008, Leonard Richardson proposed the following maturity model for web
APIs:
Level 0: Define one URI, and all operations are POST requests to this URI.
Level 1: Create separate URIs for individual resources.
Level 2: Use HTTP methods to define operations on resources.
Level 3: Use hypermedia (HATEOAS, described below).
Level 3 corresponds to a truly RESTful API according to Fielding's
definition. In practice, many published web APIs fall somewhere around level
2.
按这段话，反着看那就是越往高处越不强壮。
这里的强壮
我的意思是：
1. 空间上，尽可能多种类型设置的服务器都可以跑
2.时间上，5年后不管http server高端人口怎么折腾。
代码还是没问题。
我想假如按这两条要求的话。level 0,1应该是可以满足的。
其实的可能都够呛。
: 1. 如果有增删改，还是建议遵守Restful规范，我使用了很长时间，有些
API相
当复杂
: ，在增删改部分，Restful 规范还是相当合用。我只在查询这块遇到过问
题。规
范的目
: 的主要是让团队、合作者、上下游的客户能够方便的理解和使用API。
: 2. 关于URL的安全问题：如果的你API是给其他应用的，不会在浏览器里
使用，
其他人
: 是无法直接用“肉眼”看到的。在传输过程中，安全问题可以
通过HTTPS解决，
当然你
: 可以自己加密。如果API在浏览器里大量使用（比如通过AJAX），那么是
很容易
被前端
: 工具截取的。
: 3. 关于URL关键内容加密，这里有个方案，或许对你有帮助。因为一些原
因，我
曾经开
: 发过一些加密过的API，主要是增加破解者通过API抓取和分析数据的难度
。基本
方式是
: ，对所有的document id进行有时间戳的加密。基本方式是：
【在 s******e 的大作中提到】
: 1. 如果有增删改，还是建议遵守Restful规范，我使用了很长时间，有些API相当复杂
: ，在增删改部分，Restful 规范还是相当合用。我只在查询这块遇到过问题。规范的目
: 的主要是让团队、合作者、上下游的客户能够方便的理解和使用API。
: 2. 关于URL的安全问题：如果的你API是给其他应用的，不会在浏览器里使用，其他人
: 是无法直接用“肉眼”看到的。在传输过程中，安全问题可以通过HTTPS解决，当然你
: 可以自己加密。如果API在浏览器里大量使用（比如通过AJAX），那么是很容易被前端
: 工具截取的。
: 3. 关于URL关键内容加密，这里有个方案，或许对你有帮助。因为一些原因，我曾经开
: 发过一些加密过的API，主要是增加破解者通过API抓取和分析数据的难度。基本方式是
: ，对所有的document id进行有时间戳的加密。基本方式是：
里面有一小段话我想反着讨论下:
In 2008, Leonard Richardson proposed the following maturity model for web
APIs:
Level 0: Define one URI, and all operations are POST requests to this URI.
Level 1: Create separate URIs for individual resources.
Level 2: Use HTTP methods to define operations on resources.
Level 3: Use hypermedia (HATEOAS, described below).
Level 3 corresponds to a truly RESTful API according to Fielding's
definition. In practice, many published web APIs fall somewhere around level
2.
按这段话，反着看那就是越往高处越不强壮。
这里的强壮
我的意思是：
1. 空间上，尽可能多种类型设置的服务器都可以跑
2.时间上，5年后不管http server高端人口怎么折腾。
代码还是没问题。
我想假如按这两条要求的话。level 0,1应该是可以满足的。
其实的可能都够呛。
: 1. 如果有增删改，还是建议遵守Restful规范，我使用了很长时间，有些
API相
当复杂
: ，在增删改部分，Restful 规范还是相当合用。我只在查询这块遇到过问
题。规
范的目
: 的主要是让团队、合作者、上下游的客户能够方便的理解和使用API。
: 2. 关于URL的安全问题：如果的你API是给其他应用的，不会在浏览器里
使用，
其他人
: 是无法直接用“肉眼”看到的。在传输过程中，安全问题可以
通过HTTPS解决，
当然你
: 可以自己加密。如果API在浏览器里大量使用（比如通过AJAX），那么是
很容易
被前端
: 工具截取的。
: 3. 关于URL关键内容加密，这里有个方案，或许对你有帮助。因为一些原
因，我
曾经开
: 发过一些加密过的API，主要是增加破解者通过API抓取和分析数据的难度
。基本
方式是
: ，对所有的document id进行有时间戳的加密。基本方式是：
【在 s******e 的大作中提到】
: 1. 如果有增删改，还是建议遵守Restful规范，我使用了很长时间，有些API相当复杂
: ，在增删改部分，Restful 规范还是相当合用。我只在查询这块遇到过问题。规范的目
: 的主要是让团队、合作者、上下游的客户能够方便的理解和使用API。
: 2. 关于URL的安全问题：如果的你API是给其他应用的，不会在浏览器里使用，其他人
: 是无法直接用“肉眼”看到的。在传输过程中，安全问题可以通过HTTPS解决，当然你
: 可以自己加密。如果API在浏览器里大量使用（比如通过AJAX），那么是很容易被前端
: 工具截取的。
: 3. 关于URL关键内容加密，这里有个方案，或许对你有帮助。因为一些原因，我曾经开
: 发过一些加密过的API，主要是增加破解者通过API抓取和分析数据的难度。基本方式是
: ，对所有的document id进行有时间戳的加密。基本方式是：
g*t
24 楼
你说的加密那段我还没研究。回头再细看看。
本版高人无数啊。
: 我读了下Microsoft 的规范，挺有道理。
: 里面有一小段话我想反着讨论下:
: In 2008, Leonard Richardson proposed the following maturity model for
web
: APIs:
: Level 0: Define one URI, and all operations are POST requests to this
URI.
: Level 1: Create separate URIs for individual resources.
: Level 2: Use HTTP methods to define operations on resources.
: Level 3: Use hypermedia (HATEOAS, described below).
: Level 3 corresponds to a truly RESTful API according to Fielding's
: definition. In practice, many published web APIs fall somewhere around
level
【在 g****t 的大作中提到】
: 我读了下Microsoft 的规范，规范确实有自己的道理。
: 里面有一小段话我想反着讨论下:
: In 2008, Leonard Richardson proposed the following maturity model for web
: APIs:
: Level 0: Define one URI, and all operations are POST requests to this URI.
: Level 1: Create separate URIs for individual resources.
: Level 2: Use HTTP methods to define operations on resources.
: Level 3: Use hypermedia (HATEOAS, described below).
: Level 3 corresponds to a truly RESTful API according to Fielding's
: definition. In practice, many published web APIs fall somewhere around level
本版高人无数啊。
: 我读了下Microsoft 的规范，挺有道理。
: 里面有一小段话我想反着讨论下:
: In 2008, Leonard Richardson proposed the following maturity model for
web
: APIs:
: Level 0: Define one URI, and all operations are POST requests to this
URI.
: Level 1: Create separate URIs for individual resources.
: Level 2: Use HTTP methods to define operations on resources.
: Level 3: Use hypermedia (HATEOAS, described below).
: Level 3 corresponds to a truly RESTful API according to Fielding's
: definition. In practice, many published web APIs fall somewhere around
level
【在 g****t 的大作中提到】
: 我读了下Microsoft 的规范，规范确实有自己的道理。
: 里面有一小段话我想反着讨论下:
: In 2008, Leonard Richardson proposed the following maturity model for web
: APIs:
: Level 0: Define one URI, and all operations are POST requests to this URI.
: Level 1: Create separate URIs for individual resources.
: Level 2: Use HTTP methods to define operations on resources.
: Level 3: Use hypermedia (HATEOAS, described below).
: Level 3 corresponds to a truly RESTful API according to Fielding's
: definition. In practice, many published web APIs fall somewhere around level
s*e
25 楼
我只用到Level2，并在努力靠近中。
我的理解:HATEOAS 的目的是让API自我阐释，这样客户端可以不用预先知道某个资源，
即API，是否支持某些操作。
以前设计一些API时，需要兼顾手机和网页，当时没有很好的支持它的客户端，尤其是
iOS端，所以没有使用 HATEOAS
你的应用情况不了解，不好评论。一般情况下，level2足够了，而且还看上去非常规范
，符合一些强迫症患者的癖好。
基于API的前后端设计，普遍的问题是解耦合，即前端页面和后端实体数据间的去耦合
。其中最难搞定的是复合查询和复杂查询。
我这儿常用的做法是复合，复杂查询只返回文档或实体ID列表，然后通过单个或批量ID
请求，获取实体内容。单个的请求使用HTTP的if-modify-since，批量的，通过JSON实
现类似功能。这样的好处是:
1. 代码简单，通过IDs获取文档是非常基本的功能
2. 数据库优化容易，查询速度快，无论是RDBMS还是NoSQL
3. 去耦合，没有复合数据，前后端可以有独立的缓存
4. 复杂查询代码可以和其他代码分离，便于维护
另外，API的HTTP返回代码和错误返回内容，也需要设计一下
: 你说的加密那段我还没研究。回头再细看看。
: 本版高人无数啊。
: web
: URI.
: level
【在 g****t 的大作中提到】
: 你说的加密那段我还没研究。回头再细看看。
: 本版高人无数啊。
:
:
: 我读了下Microsoft 的规范，挺有道理。
:
: 里面有一小段话我想反着讨论下:
:
: In 2008, Leonard Richardson proposed the following maturity model for
: web
:
: APIs:
:
: Level 0: Define one URI, and all operations are POST requests to this
: URI.
我的理解:HATEOAS 的目的是让API自我阐释，这样客户端可以不用预先知道某个资源，
即API，是否支持某些操作。
以前设计一些API时，需要兼顾手机和网页，当时没有很好的支持它的客户端，尤其是
iOS端，所以没有使用 HATEOAS
你的应用情况不了解，不好评论。一般情况下，level2足够了，而且还看上去非常规范
，符合一些强迫症患者的癖好。
基于API的前后端设计，普遍的问题是解耦合，即前端页面和后端实体数据间的去耦合
。其中最难搞定的是复合查询和复杂查询。
我这儿常用的做法是复合，复杂查询只返回文档或实体ID列表，然后通过单个或批量ID
请求，获取实体内容。单个的请求使用HTTP的if-modify-since，批量的，通过JSON实
现类似功能。这样的好处是:
1. 代码简单，通过IDs获取文档是非常基本的功能
2. 数据库优化容易，查询速度快，无论是RDBMS还是NoSQL
3. 去耦合，没有复合数据，前后端可以有独立的缓存
4. 复杂查询代码可以和其他代码分离，便于维护
另外，API的HTTP返回代码和错误返回内容，也需要设计一下
: 你说的加密那段我还没研究。回头再细看看。
: 本版高人无数啊。
: web
: URI.
: level
【在 g****t 的大作中提到】
: 你说的加密那段我还没研究。回头再细看看。
: 本版高人无数啊。
:
:
: 我读了下Microsoft 的规范，挺有道理。
:
: 里面有一小段话我想反着讨论下:
:
: In 2008, Leonard Richardson proposed the following maturity model for
: web
:
: APIs:
:
: Level 0: Define one URI, and all operations are POST requests to this
: URI.
g*t
26 楼
我写过网站。后来20年没碰了。前些天休息下，有时间写代码。正好有个猎头发了
一个题给我，查询，增删，归类一个csv商品目录什么的。
除了前面说的post的办法。稍复杂查询我写了几句SQL模版，比如
Select x from y where z
写在API里。
x,y,x用http post 从客户端传json到服务器。
这样API 合成一个SQL句子，发数据库。
我的思维比较发散。现在想写一个线性代数计算
的API 服务器自用(Wdong应该已经有了) ----这叫micro services? 既然是无网页的数
值计算。那就不讲究了，
可能level 0, level 1是适合我的。
不怕大家笑话。我真的写过验证黎曼猜想的程序。
: 我只用到Level2，并在努力靠近中。
: 我的理解:HATEOAS 的目的是让API自我阐释，这样客户端可以不用预先知
道某个
资源，
: 即API，是否支持某些操作。
: 以前设计一些API时，需要兼顾手机和网页，当时没有很好的支持它的客
户端，
尤其是
: iOS端，所以没有使用 HATEOAS
: 你的应用情况不了解，不好评论。一般情况下，level2足够了，而且还看
上去非
常规范
: ，符合一些强迫症患者的癖好。
: 基于API的前后端设计，普遍的问题是解耦合，即前端页面和后端实体数
据间的
去耦合
: 。其中最难搞定的是复合查询和复杂查询。
: 我这儿常用的做法是复合，复杂查询只返回文档或实体ID列表，然后通过
单个或
批量ID
【在 s******e 的大作中提到】
: 我只用到Level2，并在努力靠近中。
: 我的理解:HATEOAS 的目的是让API自我阐释，这样客户端可以不用预先知道某个资源，
: 即API，是否支持某些操作。
: 以前设计一些API时，需要兼顾手机和网页，当时没有很好的支持它的客户端，尤其是
: iOS端，所以没有使用 HATEOAS
: 你的应用情况不了解，不好评论。一般情况下，level2足够了，而且还看上去非常规范
: ，符合一些强迫症患者的癖好。
: 基于API的前后端设计，普遍的问题是解耦合，即前端页面和后端实体数据间的去耦合
: 。其中最难搞定的是复合查询和复杂查询。
: 我这儿常用的做法是复合，复杂查询只返回文档或实体ID列表，然后通过单个或批量ID
一个题给我，查询，增删，归类一个csv商品目录什么的。
除了前面说的post的办法。稍复杂查询我写了几句SQL模版，比如
Select x from y where z
写在API里。
x,y,x用http post 从客户端传json到服务器。
这样API 合成一个SQL句子，发数据库。
我的思维比较发散。现在想写一个线性代数计算
的API 服务器自用(Wdong应该已经有了) ----这叫micro services? 既然是无网页的数
值计算。那就不讲究了，
可能level 0, level 1是适合我的。
不怕大家笑话。我真的写过验证黎曼猜想的程序。
: 我只用到Level2，并在努力靠近中。
: 我的理解:HATEOAS 的目的是让API自我阐释，这样客户端可以不用预先知
道某个
资源，
: 即API，是否支持某些操作。
: 以前设计一些API时，需要兼顾手机和网页，当时没有很好的支持它的客
户端，
尤其是
: iOS端，所以没有使用 HATEOAS
: 你的应用情况不了解，不好评论。一般情况下，level2足够了，而且还看
上去非
常规范
: ，符合一些强迫症患者的癖好。
: 基于API的前后端设计，普遍的问题是解耦合，即前端页面和后端实体数
据间的
去耦合
: 。其中最难搞定的是复合查询和复杂查询。
: 我这儿常用的做法是复合，复杂查询只返回文档或实体ID列表，然后通过
单个或
批量ID
【在 s******e 的大作中提到】
: 我只用到Level2，并在努力靠近中。
: 我的理解:HATEOAS 的目的是让API自我阐释，这样客户端可以不用预先知道某个资源，
: 即API，是否支持某些操作。
: 以前设计一些API时，需要兼顾手机和网页，当时没有很好的支持它的客户端，尤其是
: iOS端，所以没有使用 HATEOAS
: 你的应用情况不了解，不好评论。一般情况下，level2足够了，而且还看上去非常规范
: ，符合一些强迫症患者的癖好。
: 基于API的前后端设计，普遍的问题是解耦合，即前端页面和后端实体数据间的去耦合
: 。其中最难搞定的是复合查询和复杂查询。
: 我这儿常用的做法是复合，复杂查询只返回文档或实体ID列表，然后通过单个或批量ID
l*s
27 楼
大牛，请收下我的膝盖 ：-）
【在 s******e 的大作中提到】
: 根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“GET”对
: 应的那部分。
: 使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
: Restful 不太完备。主要的限制是：
: 1. HTTP 里的 GET 是有长度限制的
: 目前主流产品（apache，tomcat，jetty，haproxy等）的默认长度是8K-16K，如果是代
: 理，像haproxy，实际使用内存翻倍，因为它需要 URL rewrite。这个长度是HTTP头和
: URL共享的，如果头部（cookie，host info，auth等）内容太多，URL的长度会进一步
: 受限。如果你的查询API非常复杂，那么使用GET就会碰到长度限制问题。
: 2. 标准协议不支持 GET + RequestBody
【在 s******e 的大作中提到】
: 根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“GET”对
: 应的那部分。
: 使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
: Restful 不太完备。主要的限制是：
: 1. HTTP 里的 GET 是有长度限制的
: 目前主流产品（apache，tomcat，jetty，haproxy等）的默认长度是8K-16K，如果是代
: 理，像haproxy，实际使用内存翻倍，因为它需要 URL rewrite。这个长度是HTTP头和
: URL共享的，如果头部（cookie，host info，auth等）内容太多，URL的长度会进一步
: 受限。如果你的查询API非常复杂，那么使用GET就会碰到长度限制问题。
: 2. 标准协议不支持 GET + RequestBody
s*e
28 楼
CSV商品目录应该很容易做成微服务，完全实现level2，甚至level3也很直观。
线性代数那个API，我脑子里还没具体概念，具体端点设计不好说; 用HTTP JSON做协议
载体应该可以; 但或许也可以考虑狗家的protobuf，更高效，符合矩阵计算的要求。
: 我写过网站。后来20年没碰了。前些天休息下，有时间写代码。正好有个猎头发了
: 一个题给我，查询，增删，归类一个csv商品目录什么的。
: 除了前面说的post的办法。稍复杂查询我写了几句SQL模版，比如
: Select x from y where z
: 写在API里。
: x,y,x用http post 从客户端传json到服务器。
: 这样API 合成一个SQL句子，发数据库。
: 我的思维比较发散。现在想写一个线性代数计算
: 的API 服务器自用(Wdong应该已经有了) ----这叫micro services? 既然是无网
页的数
: 值计算。那就不讲究了，
【在 g****t 的大作中提到】
: 我写过网站。后来20年没碰了。前些天休息下，有时间写代码。正好有个猎头发了
: 一个题给我，查询，增删，归类一个csv商品目录什么的。
: 除了前面说的post的办法。稍复杂查询我写了几句SQL模版，比如
: Select x from y where z
: 写在API里。
: x,y,x用http post 从客户端传json到服务器。
: 这样API 合成一个SQL句子，发数据库。
: 我的思维比较发散。现在想写一个线性代数计算
: 的API 服务器自用(Wdong应该已经有了) ----这叫micro services? 既然是无网页的数
: 值计算。那就不讲究了，
线性代数那个API，我脑子里还没具体概念，具体端点设计不好说; 用HTTP JSON做协议
载体应该可以; 但或许也可以考虑狗家的protobuf，更高效，符合矩阵计算的要求。
: 我写过网站。后来20年没碰了。前些天休息下，有时间写代码。正好有个猎头发了
: 一个题给我，查询，增删，归类一个csv商品目录什么的。
: 除了前面说的post的办法。稍复杂查询我写了几句SQL模版，比如
: Select x from y where z
: 写在API里。
: x,y,x用http post 从客户端传json到服务器。
: 这样API 合成一个SQL句子，发数据库。
: 我的思维比较发散。现在想写一个线性代数计算
: 的API 服务器自用(Wdong应该已经有了) ----这叫micro services? 既然是无网
页的数
: 值计算。那就不讲究了，
【在 g****t 的大作中提到】
: 我写过网站。后来20年没碰了。前些天休息下，有时间写代码。正好有个猎头发了
: 一个题给我，查询，增删，归类一个csv商品目录什么的。
: 除了前面说的post的办法。稍复杂查询我写了几句SQL模版，比如
: Select x from y where z
: 写在API里。
: x,y,x用http post 从客户端传json到服务器。
: 这样API 合成一个SQL句子，发数据库。
: 我的思维比较发散。现在想写一个线性代数计算
: 的API 服务器自用(Wdong应该已经有了) ----这叫micro services? 既然是无网页的数
: 值计算。那就不讲究了，
g*t
29 楼
Json很多语言都工具链齐备。
: CSV商品目录应该很容易做成微服务，完全实现level2，甚至level3也很直观。
: 线性代数那个API，我脑子里还没具体概念，具体端点设计不好说; 用HTTP JSON
做协议
: 载体应该可以; 但或许也可以考虑狗家的protobuf，更高效，符合矩阵计算的要
求。
: 页的数
【在 s******e 的大作中提到】
: CSV商品目录应该很容易做成微服务，完全实现level2，甚至level3也很直观。
: 线性代数那个API，我脑子里还没具体概念，具体端点设计不好说; 用HTTP JSON做协议
: 载体应该可以; 但或许也可以考虑狗家的protobuf，更高效，符合矩阵计算的要求。
:
:
: 我写过网站。后来20年没碰了。前些天休息下，有时间写代码。正好有个猎头发了
:
: 一个题给我，查询，增删，归类一个csv商品目录什么的。
:
: 除了前面说的post的办法。稍复杂查询我写了几句SQL模版，比如
:
: Select x from y where z
:
: 写在API里。
:
: x,y,x用http post 从客户端传json到服务器。
: CSV商品目录应该很容易做成微服务，完全实现level2，甚至level3也很直观。
: 线性代数那个API，我脑子里还没具体概念，具体端点设计不好说; 用HTTP JSON
做协议
: 载体应该可以; 但或许也可以考虑狗家的protobuf，更高效，符合矩阵计算的要
求。
: 页的数
【在 s******e 的大作中提到】
: CSV商品目录应该很容易做成微服务，完全实现level2，甚至level3也很直观。
: 线性代数那个API，我脑子里还没具体概念，具体端点设计不好说; 用HTTP JSON做协议
: 载体应该可以; 但或许也可以考虑狗家的protobuf，更高效，符合矩阵计算的要求。
:
:
: 我写过网站。后来20年没碰了。前些天休息下，有时间写代码。正好有个猎头发了
:
: 一个题给我，查询，增删，归类一个csv商品目录什么的。
:
: 除了前面说的post的办法。稍复杂查询我写了几句SQL模版，比如
:
: Select x from y where z
:
: 写在API里。
:
: x,y,x用http post 从客户端传json到服务器。
w*m
30 楼
我研究了一下，REST的起源是，大概2000年左右受到了java里面dependency injection
的启发。
动态资源静态化。万物皆资源。
后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东西。
真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.zhihu.com/p/
20034107
默认前后端没有直接沟通，而且没有文档，所以有HATEOAS要自我阐释。
要是前端要加一个less than之类的filter，就麻烦了。
gRPC比较好，最少有个互相沟通的文档的。
以后http2和gRPC web成熟了，可能REST不会像现在这么普及。
ID
【在 s******e 的大作中提到】
: 我只用到Level2，并在努力靠近中。
: 我的理解:HATEOAS 的目的是让API自我阐释，这样客户端可以不用预先知道某个资源，
: 即API，是否支持某些操作。
: 以前设计一些API时，需要兼顾手机和网页，当时没有很好的支持它的客户端，尤其是
: iOS端，所以没有使用 HATEOAS
: 你的应用情况不了解，不好评论。一般情况下，level2足够了，而且还看上去非常规范
: ，符合一些强迫症患者的癖好。
: 基于API的前后端设计，普遍的问题是解耦合，即前端页面和后端实体数据间的去耦合
: 。其中最难搞定的是复合查询和复杂查询。
: 我这儿常用的做法是复合，复杂查询只返回文档或实体ID列表，然后通过单个或批量ID
的启发。
动态资源静态化。万物皆资源。
后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东西。
真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.zhihu.com/p/
20034107
默认前后端没有直接沟通，而且没有文档，所以有HATEOAS要自我阐释。
要是前端要加一个less than之类的filter，就麻烦了。
gRPC比较好，最少有个互相沟通的文档的。
以后http2和gRPC web成熟了，可能REST不会像现在这么普及。
ID
【在 s******e 的大作中提到】
: 我只用到Level2，并在努力靠近中。
: 我的理解:HATEOAS 的目的是让API自我阐释，这样客户端可以不用预先知道某个资源，
: 即API，是否支持某些操作。
: 以前设计一些API时，需要兼顾手机和网页，当时没有很好的支持它的客户端，尤其是
: iOS端，所以没有使用 HATEOAS
: 你的应用情况不了解，不好评论。一般情况下，level2足够了，而且还看上去非常规范
: ，符合一些强迫症患者的癖好。
: 基于API的前后端设计，普遍的问题是解耦合，即前端页面和后端实体数据间的去耦合
: 。其中最难搞定的是复合查询和复杂查询。
: 我这儿常用的做法是复合，复杂查询只返回文档或实体ID列表，然后通过单个或批量ID
s*e
31 楼
同意，工具和轮子是需要考虑
: Json很多语言都工具链齐备。
: 做协议
: 求。
【在 g****t 的大作中提到】
: Json很多语言都工具链齐备。
:
:
: CSV商品目录应该很容易做成微服务，完全实现level2，甚至level3也很直观。
:
: 线性代数那个API，我脑子里还没具体概念，具体端点设计不好说; 用HTTP JSON
: 做协议
:
: 载体应该可以; 但或许也可以考虑狗家的protobuf，更高效，符合矩阵计算的要
: 求。
:
: 页的数
:
: Json很多语言都工具链齐备。
: 做协议
: 求。
【在 g****t 的大作中提到】
: Json很多语言都工具链齐备。
:
:
: CSV商品目录应该很容易做成微服务，完全实现level2，甚至level3也很直观。
:
: 线性代数那个API，我脑子里还没具体概念，具体端点设计不好说; 用HTTP JSON
: 做协议
:
: 载体应该可以; 但或许也可以考虑狗家的protobuf，更高效，符合矩阵计算的要
: 求。
:
: 页的数
:
s*e
32 楼
狗家的很多技术是比较符合技术宅的口味，但是狗家不是Sun公司，他们其实对开源不
太友好，很多东西说不支持，就立马死掉了。所以我用狗家的东西，都先衡量一下自己
产品的生命周期。不知其他人是否有同感。
: 我研究了一下，REST的起源是，大概2000年左右受到了java里面dependency
injection
: 的启发。
: 动态资源静态化。万物皆资源。
: 后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东西。
: 真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.zhihu.com
/p/
: 20034107
: 默认前后端没有直接沟通，而且没有文档，所以有HATEOAS要自我阐释。
: 要是前端要加一个less than之类的filter，就麻烦了。
: gRPC比较好，最少有个互相沟通的文档的。
: 以后http2和gRPC web成熟了，可能REST不会像现在这么普及。
【在 w********m 的大作中提到】
: 我研究了一下，REST的起源是，大概2000年左右受到了java里面dependency injection
: 的启发。
: 动态资源静态化。万物皆资源。
: 后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东西。
: 真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.zhihu.com/p/
: 20034107
: 默认前后端没有直接沟通，而且没有文档，所以有HATEOAS要自我阐释。
: 要是前端要加一个less than之类的filter，就麻烦了。
: gRPC比较好，最少有个互相沟通的文档的。
: 以后http2和gRPC web成熟了，可能REST不会像现在这么普及。
太友好，很多东西说不支持，就立马死掉了。所以我用狗家的东西，都先衡量一下自己
产品的生命周期。不知其他人是否有同感。
: 我研究了一下，REST的起源是，大概2000年左右受到了java里面dependency
injection
: 的启发。
: 动态资源静态化。万物皆资源。
: 后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东西。
: 真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.zhihu.com
/p/
: 20034107
: 默认前后端没有直接沟通，而且没有文档，所以有HATEOAS要自我阐释。
: 要是前端要加一个less than之类的filter，就麻烦了。
: gRPC比较好，最少有个互相沟通的文档的。
: 以后http2和gRPC web成熟了，可能REST不会像现在这么普及。
【在 w********m 的大作中提到】
: 我研究了一下，REST的起源是，大概2000年左右受到了java里面dependency injection
: 的启发。
: 动态资源静态化。万物皆资源。
: 后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东西。
: 真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.zhihu.com/p/
: 20034107
: 默认前后端没有直接沟通，而且没有文档，所以有HATEOAS要自我阐释。
: 要是前端要加一个less than之类的filter，就麻烦了。
: gRPC比较好，最少有个互相沟通的文档的。
: 以后http2和gRPC web成熟了，可能REST不会像现在这么普及。
w*m
33 楼
我个人对狗狗没有什么好感。
但没办法啊，现在狗狗的技术基本定义了整个IT圈。
相比别的公司，狗狗可能还稍微可靠一点。
比起gPRC, facebook的graphql更不靠谱。
总之，狗狗非常不喜欢REST。
打个比方，golang里面有无数rpc的库，就是不支持REST。
看这回，狗狗要不要来定义web接口了。
com
【在 s******e 的大作中提到】
: 狗家的很多技术是比较符合技术宅的口味，但是狗家不是Sun公司，他们其实对开源不
: 太友好，很多东西说不支持，就立马死掉了。所以我用狗家的东西，都先衡量一下自己
: 产品的生命周期。不知其他人是否有同感。
:
:
: 我研究了一下，REST的起源是，大概2000年左右受到了java里面dependency
: injection
:
: 的启发。
:
: 动态资源静态化。万物皆资源。
:
: 后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东西。
:
: 真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.zhihu.com
但没办法啊，现在狗狗的技术基本定义了整个IT圈。
相比别的公司，狗狗可能还稍微可靠一点。
比起gPRC, facebook的graphql更不靠谱。
总之，狗狗非常不喜欢REST。
打个比方，golang里面有无数rpc的库，就是不支持REST。
看这回，狗狗要不要来定义web接口了。
com
【在 s******e 的大作中提到】
: 狗家的很多技术是比较符合技术宅的口味，但是狗家不是Sun公司，他们其实对开源不
: 太友好，很多东西说不支持，就立马死掉了。所以我用狗家的东西，都先衡量一下自己
: 产品的生命周期。不知其他人是否有同感。
:
:
: 我研究了一下，REST的起源是，大概2000年左右受到了java里面dependency
: injection
:
: 的启发。
:
: 动态资源静态化。万物皆资源。
:
: 后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东西。
:
: 真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.zhihu.com
l*9
34 楼
good topic。thanks
g*t
35 楼
REST不是说设计http 1.1的高端人士的phd论文吗……
我个人的看法（你从这个帖子就可以看到了），如果是做
massive market product，
最重要
Axioms,是市场里面里面，最大范围的http服务器这个集体的共性：能传什么，不能传
什么。这是第一个圈。
第二重要的是tool chain.这是第二个圈。
别的都是次要的。属于圈内再画圈。
: 我研究了一下，REST的起源是，大概2000年左右受到了java里面
dependency
injection
: 的启发。
: 动态资源静态化。万物皆资源。
: 后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东
西。
: 真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.
zhihu.com
/p/
: 20034107
: 默认前后端没有直接沟通，而且没有文档，所以有HATEOAS要自我阐释。
: 要是前端要加一个less than之类的filter，就麻烦了。
: gRPC比较好，最少有个互相沟通的文档的。
: 以后http2和gRPC web成熟了，可能REST不会像现在这么普及。
【在 w********m 的大作中提到】
: 我个人对狗狗没有什么好感。
: 但没办法啊，现在狗狗的技术基本定义了整个IT圈。
: 相比别的公司，狗狗可能还稍微可靠一点。
: 比起gPRC, facebook的graphql更不靠谱。
: 总之，狗狗非常不喜欢REST。
: 打个比方，golang里面有无数rpc的库，就是不支持REST。
: 看这回，狗狗要不要来定义web接口了。
:
: com
我个人的看法（你从这个帖子就可以看到了），如果是做
massive market product，
最重要
Axioms,是市场里面里面，最大范围的http服务器这个集体的共性：能传什么，不能传
什么。这是第一个圈。
第二重要的是tool chain.这是第二个圈。
别的都是次要的。属于圈内再画圈。
: 我研究了一下，REST的起源是，大概2000年左右受到了java里面
dependency
injection
: 的启发。
: 动态资源静态化。万物皆资源。
: 后端程序员写一个repository类似的资源桶，然后前端程序员到里面捡东
西。
: 真正讲究起来，很难写的对，讲究的东西太多了。https://zhuanlan.
zhihu.com
/p/
: 20034107
: 默认前后端没有直接沟通，而且没有文档，所以有HATEOAS要自我阐释。
: 要是前端要加一个less than之类的filter，就麻烦了。
: gRPC比较好，最少有个互相沟通的文档的。
: 以后http2和gRPC web成熟了，可能REST不会像现在这么普及。
【在 w********m 的大作中提到】
: 我个人对狗狗没有什么好感。
: 但没办法啊，现在狗狗的技术基本定义了整个IT圈。
: 相比别的公司，狗狗可能还稍微可靠一点。
: 比起gPRC, facebook的graphql更不靠谱。
: 总之，狗狗非常不喜欢REST。
: 打个比方，golang里面有无数rpc的库，就是不支持REST。
: 看这回，狗狗要不要来定义web接口了。
:
: com
g*t
36 楼
我看Google不是不支持rest
是他家的支持比较多样化
因为研发人员总要做些假项目领工资嘛
谁也不能保证每个产品都流行
像我这样0知识的
就选http POST/GET json
别的不碰
免得将来被害死
: 我个人对狗狗没有什么好感。
: 但没办法啊，现在狗狗的技术基本定义了整个IT圈。
: 相比别的公司，狗狗可能还稍微可靠一点。
: 比起gPRC, facebook的graphql更不靠谱。
: 总之，狗狗非常不喜欢REST。
: 打个比方，golang里面有无数rpc的库，就是不支持REST。
: 看这回，狗狗要不要来定义web接口了。
: com
【在 w********m 的大作中提到】
: 我个人对狗狗没有什么好感。
: 但没办法啊，现在狗狗的技术基本定义了整个IT圈。
: 相比别的公司，狗狗可能还稍微可靠一点。
: 比起gPRC, facebook的graphql更不靠谱。
: 总之，狗狗非常不喜欢REST。
: 打个比方，golang里面有无数rpc的库，就是不支持REST。
: 看这回，狗狗要不要来定义web接口了。
:
: com
是他家的支持比较多样化
因为研发人员总要做些假项目领工资嘛
谁也不能保证每个产品都流行
像我这样0知识的
就选http POST/GET json
别的不碰
免得将来被害死
: 我个人对狗狗没有什么好感。
: 但没办法啊，现在狗狗的技术基本定义了整个IT圈。
: 相比别的公司，狗狗可能还稍微可靠一点。
: 比起gPRC, facebook的graphql更不靠谱。
: 总之，狗狗非常不喜欢REST。
: 打个比方，golang里面有无数rpc的库，就是不支持REST。
: 看这回，狗狗要不要来定义web接口了。
: com
【在 w********m 的大作中提到】
: 我个人对狗狗没有什么好感。
: 但没办法啊，现在狗狗的技术基本定义了整个IT圈。
: 相比别的公司，狗狗可能还稍微可靠一点。
: 比起gPRC, facebook的graphql更不靠谱。
: 总之，狗狗非常不喜欢REST。
: 打个比方，golang里面有无数rpc的库，就是不支持REST。
: 看这回，狗狗要不要来定义web接口了。
:
: com
b*s
37 楼
如果设计的好，应该不会有特别复杂的查询或者超长之类的。micro-service就是要切
碎嘛。能遵守规范的尽量还是应该遵守。
【在 s******e 的大作中提到】
: 根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“GET”对
: 应的那部分。
: 使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
: Restful 不太完备。主要的限制是：
: 1. HTTP 里的 GET 是有长度限制的
: 目前主流产品（apache，tomcat，jetty，haproxy等）的默认长度是8K-16K，如果是代
: 理，像haproxy，实际使用内存翻倍，因为它需要 URL rewrite。这个长度是HTTP头和
: URL共享的，如果头部（cookie，host info，auth等）内容太多，URL的长度会进一步
: 受限。如果你的查询API非常复杂，那么使用GET就会碰到长度限制问题。
: 2. 标准协议不支持 GET + RequestBody
碎嘛。能遵守规范的尽量还是应该遵守。
【在 s******e 的大作中提到】
: 根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“GET”对
: 应的那部分。
: 使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
: Restful 不太完备。主要的限制是：
: 1. HTTP 里的 GET 是有长度限制的
: 目前主流产品（apache，tomcat，jetty，haproxy等）的默认长度是8K-16K，如果是代
: 理，像haproxy，实际使用内存翻倍，因为它需要 URL rewrite。这个长度是HTTP头和
: URL共享的，如果头部（cookie，host info，auth等）内容太多，URL的长度会进一步
: 受限。如果你的查询API非常复杂，那么使用GET就会碰到长度限制问题。
: 2. 标准协议不支持 GET + RequestBody
b*s
38 楼
你看看oauth -2令牌加密是不是有用
【在 g****t 的大作中提到】
: 你这个贴太好了。需要一看再看.
: 第二条是不是还有个缺点，就是URLencode别人能看见？
: 我一般干这活都是能不让人看见的都不让人看见。
:
:
: 根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“
: GET”对
:
: 应的那部分。
:
: 使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
:
: Restful 不太完备。主要的限制是：
:
: 1. HTTP 里的 GET 是有长度限制的
【在 g****t 的大作中提到】
: 你这个贴太好了。需要一看再看.
: 第二条是不是还有个缺点，就是URLencode别人能看见？
: 我一般干这活都是能不让人看见的都不让人看见。
:
:
: 根据你的问题，感觉你是在问数据查询、资源获取这块的API，即RestFul里“
: GET”对
:
: 应的那部分。
:
: 使用 “GET” 获取资源，是Restful的一部分，但问题是 HTTP 协议和实现上对
:
: Restful 不太完备。主要的限制是：
:
: 1. HTTP 里的 GET 是有长度限制的
g*t
39 楼
规范有自己的道理。麻烦的是它经常变。复杂查询我认为不可避免啊。因为查询是人发
起的。人是很难理解的。
不是汽车火车等工业信号。
: 如果设计的好，应该不会有特别复杂的查询或者超长之类的。micro-service就
是要切
: 碎嘛。能遵守规范的尽量还是应该遵守。
【在 b********s 的大作中提到】
: 你看看oauth -2令牌加密是不是有用
起的。人是很难理解的。
不是汽车火车等工业信号。
: 如果设计的好，应该不会有特别复杂的查询或者超长之类的。micro-service就
是要切
: 碎嘛。能遵守规范的尽量还是应该遵守。
【在 b********s 的大作中提到】
: 你看看oauth -2令牌加密是不是有用
b*s
40 楼
得先定义什么是你说的复杂查询。
如果查询结果集很大，确实就不适合用rest
rest都是基于http的，这么用有点儿为了rest而rest。不过it界就流行赶时髦，没办法。
再有也可按照分页返回。
再有某些情况可以通过 graphQL一些办法来实现。
还有某些可以把需求都扔进kalfka pub sub，异步触发慢慢做
【在 g****t 的大作中提到】
: 规范有自己的道理。麻烦的是它经常变。复杂查询我认为不可避免啊。因为查询是人发
: 起的。人是很难理解的。
: 不是汽车火车等工业信号。
:
:
: 如果设计的好，应该不会有特别复杂的查询或者超长之类的。micro-service就
: 是要切
:
: 碎嘛。能遵守规范的尽量还是应该遵守。
:
如果查询结果集很大，确实就不适合用rest
rest都是基于http的，这么用有点儿为了rest而rest。不过it界就流行赶时髦，没办法。
再有也可按照分页返回。
再有某些情况可以通过 graphQL一些办法来实现。
还有某些可以把需求都扔进kalfka pub sub，异步触发慢慢做
【在 g****t 的大作中提到】
: 规范有自己的道理。麻烦的是它经常变。复杂查询我认为不可避免啊。因为查询是人发
: 起的。人是很难理解的。
: 不是汽车火车等工业信号。
:
:
: 如果设计的好，应该不会有特别复杂的查询或者超长之类的。micro-service就
: 是要切
:
: 碎嘛。能遵守规范的尽量还是应该遵守。
:
s*e
41 楼
同意应该尽量遵守规范，而且大部分情况下，是不会有问题的。但总会有些意外，因为
HTTP本身不是个很完备的协议。
【在 b********s 的大作中提到】
: 如果设计的好，应该不会有特别复杂的查询或者超长之类的。micro-service就是要切
: 碎嘛。能遵守规范的尽量还是应该遵守。
HTTP本身不是个很完备的协议。
【在 b********s 的大作中提到】
: 如果设计的好，应该不会有特别复杂的查询或者超长之类的。micro-service就是要切
: 碎嘛。能遵守规范的尽量还是应该遵守。
s*e
42 楼
关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能只
讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
我司要把一些 legacy DevOps 的东西，从数据到实际操作都微服务化，有个小印，计
算机牛校毕业，在网上放狗搜了一把，学习能力巨强，提出要做到SOA友善，分离数据
库和前端，采用google api的形式，使用graphSQL等等高大上的东西，严格采用资源化
请求，比如全部资源都是这种形式，
GET /user - 返回用户列表
GET /user/id - 返回某个用户信息
POST /user + JSON - 创建新用户
PUT /user/id + JSON - 修改新用户
DELETE /user/id - 删除
嵌套的资源，也是在容器资源里使用其他资源的 ID：
{
user: abc,
departmentId: 123,
...
}
这样的API设计不能算错。但是
1）SOA 组件也是受DevOps管理的，在部署过程如何自我管理？
2）混淆了数据服务和操作服务，数据服务，无非是增删改查，另加复杂查询，操作服
务可以是千奇百怪，各种对象，可以执行的操作不尽相同，不能很好的套用资源的方式
3）不提供复杂查询方式，强制要求前端页面使用同一套API。前端使用的是DataTables
JS插件，根本没法用。然后逼迫他们自己写表格形式的查询前端，但是，每个页面获
取数据是单个进行的，如果每页100行数据，就要发100个HTTP请求，开发人员做到吐血
，页面慢的像乌龟
4）最重要的，这个是给DevOps做的内部产品，讲究的糙猛快，搞成一个学院派产品，
根本就不合用。
所以我觉得，规范是需要尽力遵守的，但是还是要根据实际情况，结合行业特征进行平
衡设计。
讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
我司要把一些 legacy DevOps 的东西，从数据到实际操作都微服务化，有个小印，计
算机牛校毕业，在网上放狗搜了一把，学习能力巨强，提出要做到SOA友善，分离数据
库和前端，采用google api的形式，使用graphSQL等等高大上的东西，严格采用资源化
请求，比如全部资源都是这种形式，
GET /user - 返回用户列表
GET /user/id - 返回某个用户信息
POST /user + JSON - 创建新用户
PUT /user/id + JSON - 修改新用户
DELETE /user/id - 删除
嵌套的资源，也是在容器资源里使用其他资源的 ID：
{
user: abc,
departmentId: 123,
...
}
这样的API设计不能算错。但是
1）SOA 组件也是受DevOps管理的，在部署过程如何自我管理？
2）混淆了数据服务和操作服务，数据服务，无非是增删改查，另加复杂查询，操作服
务可以是千奇百怪，各种对象，可以执行的操作不尽相同，不能很好的套用资源的方式
3）不提供复杂查询方式，强制要求前端页面使用同一套API。前端使用的是DataTables
JS插件，根本没法用。然后逼迫他们自己写表格形式的查询前端，但是，每个页面获
取数据是单个进行的，如果每页100行数据，就要发100个HTTP请求，开发人员做到吐血
，页面慢的像乌龟
4）最重要的，这个是给DevOps做的内部产品，讲究的糙猛快，搞成一个学院派产品，
根本就不合用。
所以我觉得，规范是需要尽力遵守的，但是还是要根据实际情况，结合行业特征进行平
衡设计。
s*e
43 楼
OAuth 一般都用 JWT （Java Web Token），这个做普通数据加密有些大材小用了。
【在 b********s 的大作中提到】
: 你看看oauth -2令牌加密是不是有用
【在 b********s 的大作中提到】
: 你看看oauth -2令牌加密是不是有用
s*e
44 楼
学过一阵 GraphQL，想用到开发的产品里，但是最后放弃了，感觉另外一个学院派作品。
当然也有可能自己太笨，或者路子比较野，和它八字不合。
如果熟悉，请多介绍。
我觉得使用消息系统另外一个比较好的思路，消息是组件通讯另外一个常用的方式，
但一般都用在服务器端内部组件之间，在大多数情况下，比RestAPI 强大和灵活，如果
那个线性代数API是内部的，感觉比 RestApi 更合适，而且它自带异步光环，很多麻烦
都自动消散。
如果是对外，感觉不太合适。
法。
【在 b********s 的大作中提到】
: 得先定义什么是你说的复杂查询。
: 如果查询结果集很大，确实就不适合用rest
: rest都是基于http的，这么用有点儿为了rest而rest。不过it界就流行赶时髦，没办法。
: 再有也可按照分页返回。
: 再有某些情况可以通过 graphQL一些办法来实现。
: 还有某些可以把需求都扔进kalfka pub sub，异步触发慢慢做
当然也有可能自己太笨，或者路子比较野，和它八字不合。
如果熟悉，请多介绍。
我觉得使用消息系统另外一个比较好的思路，消息是组件通讯另外一个常用的方式，
但一般都用在服务器端内部组件之间，在大多数情况下，比RestAPI 强大和灵活，如果
那个线性代数API是内部的，感觉比 RestApi 更合适，而且它自带异步光环，很多麻烦
都自动消散。
如果是对外，感觉不太合适。
法。
【在 b********s 的大作中提到】
: 得先定义什么是你说的复杂查询。
: 如果查询结果集很大，确实就不适合用rest
: rest都是基于http的，这么用有点儿为了rest而rest。不过it界就流行赶时髦，没办法。
: 再有也可按照分页返回。
: 再有某些情况可以通过 graphQL一些办法来实现。
: 还有某些可以把需求都扔进kalfka pub sub，异步触发慢慢做
g*t
45 楼
For example, Yahoo finance YQL
法。
【在 b********s 的大作中提到】
: 得先定义什么是你说的复杂查询。
: 如果查询结果集很大，确实就不适合用rest
: rest都是基于http的，这么用有点儿为了rest而rest。不过it界就流行赶时髦，没办法。
: 再有也可按照分页返回。
: 再有某些情况可以通过 graphQL一些办法来实现。
: 还有某些可以把需求都扔进kalfka pub sub，异步触发慢慢做
法。
【在 b********s 的大作中提到】
: 得先定义什么是你说的复杂查询。
: 如果查询结果集很大，确实就不适合用rest
: rest都是基于http的，这么用有点儿为了rest而rest。不过it界就流行赶时髦，没办法。
: 再有也可按照分页返回。
: 再有某些情况可以通过 graphQL一些办法来实现。
: 还有某些可以把需求都扔进kalfka pub sub，异步触发慢慢做
g*t
46 楼
这个烙印phd专长是坑蒙拐骗。
假如你查查他的phd论文，一定是假的。我不认为会有意外.
复杂表格查询等于是SQL的语义空间.企图
用REST get post put这样简单的语义去覆盖。我觉得是基本错误。
【在 s******e 的大作中提到】
: 关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能只
: 讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
: 我司要把一些 legacy DevOps 的东西，从数据到实际操作都微服务化，有个小印，计
: 算机牛校毕业，在网上放狗搜了一把，学习能力巨强，提出要做到SOA友善，分离数据
: 库和前端，采用google api的形式，使用graphSQL等等高大上的东西，严格采用资源化
: 请求，比如全部资源都是这种形式，
: GET /user - 返回用户列表
: GET /user/id - 返回某个用户信息
: POST /user + JSON - 创建新用户
: PUT /user/id + JSON - 修改新用户
假如你查查他的phd论文，一定是假的。我不认为会有意外.
复杂表格查询等于是SQL的语义空间.企图
用REST get post put这样简单的语义去覆盖。我觉得是基本错误。
【在 s******e 的大作中提到】
: 关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能只
: 讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
: 我司要把一些 legacy DevOps 的东西，从数据到实际操作都微服务化，有个小印，计
: 算机牛校毕业，在网上放狗搜了一把，学习能力巨强，提出要做到SOA友善，分离数据
: 库和前端，采用google api的形式，使用graphSQL等等高大上的东西，严格采用资源化
: 请求，比如全部资源都是这种形式，
: GET /user - 返回用户列表
: GET /user/id - 返回某个用户信息
: POST /user + JSON - 创建新用户
: PUT /user/id + JSON - 修改新用户
g*t
47 楼
http get
http post
json
以此为公理做项目，不会在途中发生意外憋死。
也不需要因为时代变化而太多改变。
其实我猜REST之所以兴起，应该是服务器高端人士这些年优化了对XHR的性能，
来顺应mobile等多种客户端导致的。
品。
【在 s******e 的大作中提到】
: 学过一阵 GraphQL，想用到开发的产品里，但是最后放弃了，感觉另外一个学院派作品。
: 当然也有可能自己太笨，或者路子比较野，和它八字不合。
: 如果熟悉，请多介绍。
: 我觉得使用消息系统另外一个比较好的思路，消息是组件通讯另外一个常用的方式，
: 但一般都用在服务器端内部组件之间，在大多数情况下，比RestAPI 强大和灵活，如果
: 那个线性代数API是内部的，感觉比 RestApi 更合适，而且它自带异步光环，很多麻烦
: 都自动消散。
: 如果是对外，感觉不太合适。
:
: 法。
http post
json
以此为公理做项目，不会在途中发生意外憋死。
也不需要因为时代变化而太多改变。
其实我猜REST之所以兴起，应该是服务器高端人士这些年优化了对XHR的性能，
来顺应mobile等多种客户端导致的。
品。
【在 s******e 的大作中提到】
: 学过一阵 GraphQL，想用到开发的产品里，但是最后放弃了，感觉另外一个学院派作品。
: 当然也有可能自己太笨，或者路子比较野，和它八字不合。
: 如果熟悉，请多介绍。
: 我觉得使用消息系统另外一个比较好的思路，消息是组件通讯另外一个常用的方式，
: 但一般都用在服务器端内部组件之间，在大多数情况下，比RestAPI 强大和灵活，如果
: 那个线性代数API是内部的，感觉比 RestApi 更合适，而且它自带异步光环，很多麻烦
: 都自动消散。
: 如果是对外，感觉不太合适。
:
: 法。
t*s
48 楼
你这个JWT是指JSON Web Token吧？
【在 s******e 的大作中提到】
: OAuth 一般都用 JWT （Java Web Token），这个做普通数据加密有些大材小用了。
【在 s******e 的大作中提到】
: OAuth 一般都用 JWT （Java Web Token），这个做普通数据加密有些大材小用了。
t*s
49 楼
你这个例子很好
希望我能用它来说服我们老板
他甚至希望我们的网站都微服务化
【在 s******e 的大作中提到】
: 关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能只
: 讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
: 我司要把一些 legacy DevOps 的东西，从数据到实际操作都微服务化，有个小印，计
: 算机牛校毕业，在网上放狗搜了一把，学习能力巨强，提出要做到SOA友善，分离数据
: 库和前端，采用google api的形式，使用graphSQL等等高大上的东西，严格采用资源化
: 请求，比如全部资源都是这种形式，
: GET /user - 返回用户列表
: GET /user/id - 返回某个用户信息
: POST /user + JSON - 创建新用户
: PUT /user/id + JSON - 修改新用户
希望我能用它来说服我们老板
他甚至希望我们的网站都微服务化
【在 s******e 的大作中提到】
: 关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能只
: 讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
: 我司要把一些 legacy DevOps 的东西，从数据到实际操作都微服务化，有个小印，计
: 算机牛校毕业，在网上放狗搜了一把，学习能力巨强，提出要做到SOA友善，分离数据
: 库和前端，采用google api的形式，使用graphSQL等等高大上的东西，严格采用资源化
: 请求，比如全部资源都是这种形式，
: GET /user - 返回用户列表
: GET /user/id - 返回某个用户信息
: POST /user + JSON - 创建新用户
: PUT /user/id + JSON - 修改新用户
s*e
50 楼
谢谢指正。Java用得太多了，汉
: 你这个JWT是指JSON Web Token吧？
【在 t*****s 的大作中提到】
: 你这个例子很好
: 希望我能用它来说服我们老板
: 他甚至希望我们的网站都微服务化
: 你这个JWT是指JSON Web Token吧？
【在 t*****s 的大作中提到】
: 你这个例子很好
: 希望我能用它来说服我们老板
: 他甚至希望我们的网站都微服务化
b*s
51 楼
这个事情问题就在于是为了micro而micro。rest本来就不是高性能的东西，需要用到好
多http，那显然就不是rest应该解决的问题。这点不清楚的话，那烙印不算牛人，而是
sb。
但这个并不说明规范化的意义。这个是用错了规范。
【在 s******e 的大作中提到】
: 关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能只
: 讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
: 我司要把一些 legacy DevOps 的东西，从数据到实际操作都微服务化，有个小印，计
: 算机牛校毕业，在网上放狗搜了一把，学习能力巨强，提出要做到SOA友善，分离数据
: 库和前端，采用google api的形式，使用graphSQL等等高大上的东西，严格采用资源化
: 请求，比如全部资源都是这种形式，
: GET /user - 返回用户列表
: GET /user/id - 返回某个用户信息
: POST /user + JSON - 创建新用户
: PUT /user/id + JSON - 修改新用户
多http，那显然就不是rest应该解决的问题。这点不清楚的话，那烙印不算牛人，而是
sb。
但这个并不说明规范化的意义。这个是用错了规范。
【在 s******e 的大作中提到】
: 关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能只
: 讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
: 我司要把一些 legacy DevOps 的东西，从数据到实际操作都微服务化，有个小印，计
: 算机牛校毕业，在网上放狗搜了一把，学习能力巨强，提出要做到SOA友善，分离数据
: 库和前端，采用google api的形式，使用graphSQL等等高大上的东西，严格采用资源化
: 请求，比如全部资源都是这种形式，
: GET /user - 返回用户列表
: GET /user/id - 返回某个用户信息
: POST /user + JSON - 创建新用户
: PUT /user/id + JSON - 修改新用户
b*s
52 楼
我的理解，这东西并不是很重量级的产品。
【在 s******e 的大作中提到】
: OAuth 一般都用 JWT （Java Web Token），这个做普通数据加密有些大材小用了。
【在 s******e 的大作中提到】
: OAuth 一般都用 JWT （Java Web Token），这个做普通数据加密有些大材小用了。
b*s
53 楼
没接触过这东西，完全一头雾水，让你见笑了。
【在 g****t 的大作中提到】
: For example, Yahoo finance YQL
:
: 法。
【在 g****t 的大作中提到】
: For example, Yahoo finance YQL
:
: 法。
s*e
54 楼
特地查了yql，突然茅塞顿开，原来可以把自定义的查询DSL直接作为GET参数传入。我
原先都是使用MongoDB和restdb.io的查询方式。
: For example, Yahoo finance YQL
: 法。
【在 g****t 的大作中提到】
: http get
: http post
: json
: 以此为公理做项目，不会在途中发生意外憋死。
: 也不需要因为时代变化而太多改变。
: 其实我猜REST之所以兴起，应该是服务器高端人士这些年优化了对XHR的性能，
: 来顺应mobile等多种客户端导致的。
:
: 品。
原先都是使用MongoDB和restdb.io的查询方式。
: For example, Yahoo finance YQL
: 法。
【在 g****t 的大作中提到】
: http get
: http post
: json
: 以此为公理做项目，不会在途中发生意外憋死。
: 也不需要因为时代变化而太多改变。
: 其实我猜REST之所以兴起，应该是服务器高端人士这些年优化了对XHR的性能，
: 来顺应mobile等多种客户端导致的。
:
: 品。
s*e
55 楼
我原先说的不准确，jwt是为认证授权设计的，本身不复杂，但做通用加密不太合用
: 我的理解，这东西并不是很重量级的产品。
【在 b********s 的大作中提到】
: 没接触过这东西，完全一头雾水，让你见笑了。
: 我的理解，这东西并不是很重量级的产品。
【在 b********s 的大作中提到】
: 没接触过这东西，完全一头雾水，让你见笑了。
b*s
56 楼
那可能是我理解错了。我以为他的需求是很轻量级的保护，那么认证以后用session控
制就可以了，我没考虑要整个过程加密。
【在 s******e 的大作中提到】
: 我原先说的不准确，jwt是为认证授权设计的，本身不复杂，但做通用加密不太合用
:
:
: 我的理解，这东西并不是很重量级的产品。
:
制就可以了，我没考虑要整个过程加密。
【在 s******e 的大作中提到】
: 我原先说的不准确，jwt是为认证授权设计的，本身不复杂，但做通用加密不太合用
:
:
: 我的理解，这东西并不是很重量级的产品。
:
g*t
57 楼
就是炒股的查过去的各种财经数据。
【在 b********s 的大作中提到】
: 没接触过这东西，完全一头雾水，让你见笑了。
【在 b********s 的大作中提到】
: 没接触过这东西，完全一头雾水，让你见笑了。
c*e
58 楼
restful是没有session的，你要把你server玩趴下？
【在 g****t 的大作中提到】
: 对同一个resource,例如一张表，有7个actions,例如查询，
: 分组，等7个类似于sql那种要求。
: 那么该怎么设计API endooints什么的？
: 我的做法是：
: 全用POST method, 不理会GET POST PUT...这套。
: POST上传actions的参数，7个API的名字包含在URL里。
: 这样做优劣如何？请大家批评指正。
【在 g****t 的大作中提到】
: 对同一个resource,例如一张表，有7个actions,例如查询，
: 分组，等7个类似于sql那种要求。
: 那么该怎么设计API endooints什么的？
: 我的做法是：
: 全用POST method, 不理会GET POST PUT...这套。
: POST上传actions的参数，7个API的名字包含在URL里。
: 这样做优劣如何？请大家批评指正。
s*i
59 楼
3+ FTW! Nowdays I use only 4 HTTP methods:
GET
POST
PATCH
DELETE
PUT is special case of PATCH. I stopped using it for good. Also, I abandoned
the idea of handling single resource. Eg., DELETE would accept an array of
IDs instead of DELETE/{id}, because single ID is just a special case of [id1
, id2, ...].
level
【在 g****t 的大作中提到】
: 我读了下Microsoft 的规范，规范确实有自己的道理。
: 里面有一小段话我想反着讨论下:
: In 2008, Leonard Richardson proposed the following maturity model for web
: APIs:
: Level 0: Define one URI, and all operations are POST requests to this URI.
: Level 1: Create separate URIs for individual resources.
: Level 2: Use HTTP methods to define operations on resources.
: Level 3: Use hypermedia (HATEOAS, described below).
: Level 3 corresponds to a truly RESTful API according to Fielding's
: definition. In practice, many published web APIs fall somewhere around level
GET
POST
PATCH
DELETE
PUT is special case of PATCH. I stopped using it for good. Also, I abandoned
the idea of handling single resource. Eg., DELETE would accept an array of
IDs instead of DELETE/{id}, because single ID is just a special case of [id1
, id2, ...].
level
【在 g****t 的大作中提到】
: 我读了下Microsoft 的规范，规范确实有自己的道理。
: 里面有一小段话我想反着讨论下:
: In 2008, Leonard Richardson proposed the following maturity model for web
: APIs:
: Level 0: Define one URI, and all operations are POST requests to this URI.
: Level 1: Create separate URIs for individual resources.
: Level 2: Use HTTP methods to define operations on resources.
: Level 3: Use hypermedia (HATEOAS, described below).
: Level 3 corresponds to a truly RESTful API according to Fielding's
: definition. In practice, many published web APIs fall somewhere around level
s*e
60 楼
我们也在争论改put 为 patch，我觉得无所谓，因为产品已经上线，再去折腾就不必要。
批量处理我们是有的，但还是觉得要根据实际情况采用
其实很多技术、规范本身没有难度，高中生就可以掌握。难的是把握一个度或平衡的问
题，这个学校没法教，知道的人也往往没法系统化的讲明白，只能看别人的设计，领会
其中的考量，或者自己碰到过，折腾过，并且需要熟悉业务模型，结合技术、规范来做
，我一直觉得，这个才是老程序猿和新手的差别。
abandoned
of
id1
【在 s*i 的大作中提到】
: 3+ FTW! Nowdays I use only 4 HTTP methods:
: GET
: POST
: PATCH
: DELETE
: PUT is special case of PATCH. I stopped using it for good. Also, I abandoned
: the idea of handling single resource. Eg., DELETE would accept an array of
: IDs instead of DELETE/{id}, because single ID is just a special case of [id1
: , id2, ...].
:
批量处理我们是有的，但还是觉得要根据实际情况采用
其实很多技术、规范本身没有难度，高中生就可以掌握。难的是把握一个度或平衡的问
题，这个学校没法教，知道的人也往往没法系统化的讲明白，只能看别人的设计，领会
其中的考量，或者自己碰到过，折腾过，并且需要熟悉业务模型，结合技术、规范来做
，我一直觉得，这个才是老程序猿和新手的差别。
abandoned
of
id1
【在 s*i 的大作中提到】
: 3+ FTW! Nowdays I use only 4 HTTP methods:
: GET
: POST
: PATCH
: DELETE
: PUT is special case of PATCH. I stopped using it for good. Also, I abandoned
: the idea of handling single resource. Eg., DELETE would accept an array of
: IDs instead of DELETE/{id}, because single ID is just a special case of [id1
: , id2, ...].
:
l*s
61 楼
JWT is for authorization.
JWE/JWS is for encryption/sigining
【在 s******e 的大作中提到】
: 我原先说的不准确，jwt是为认证授权设计的，本身不复杂，但做通用加密不太合用
:
:
: 我的理解，这东西并不是很重量级的产品。
:
JWE/JWS is for encryption/sigining
【在 s******e 的大作中提到】
: 我原先说的不准确，jwt是为认证授权设计的，本身不复杂，但做通用加密不太合用
:
:
: 我的理解，这东西并不是很重量级的产品。
:
s*e
62 楼
Restful 一般是是stateless的，当然也不是绝对。
Restful 的缓存，扩展性，认证，处理大批量数据，里面还是有些门道，可以单独开贴
讨论。
Restful api 我是野路子出身，不怕大家笑话，看了点wiki介绍就开始边学边用，如果
哪位可以介绍一些资料，不胜感激。
【在 c*********e 的大作中提到】
: restful是没有session的，你要把你server玩趴下？
Restful 的缓存，扩展性，认证，处理大批量数据，里面还是有些门道，可以单独开贴
讨论。
Restful api 我是野路子出身，不怕大家笑话，看了点wiki介绍就开始边学边用，如果
哪位可以介绍一些资料，不胜感激。
【在 c*********e 的大作中提到】
: restful是没有session的，你要把你server玩趴下？
s*e
63 楼
非常感谢，学到新东西了。
回头看看。我是拿来主义者，有轮子，直接上。
【在 l***s 的大作中提到】
: JWT is for authorization.
: JWE/JWS is for encryption/sigining
回头看看。我是拿来主义者，有轮子，直接上。
【在 l***s 的大作中提到】
: JWT is for authorization.
: JWE/JWS is for encryption/sigining
g*9
64 楼
同问：谁能推荐个rest设计的经典书？用了好久，一直没兴趣系统的提高一下。
【在 s******e 的大作中提到】
: Restful 一般是是stateless的，当然也不是绝对。
: Restful 的缓存，扩展性，认证，处理大批量数据，里面还是有些门道，可以单独开贴
: 讨论。
: Restful api 我是野路子出身，不怕大家笑话，看了点wiki介绍就开始边学边用，如果
: 哪位可以介绍一些资料，不胜感激。
【在 s******e 的大作中提到】
: Restful 一般是是stateless的，当然也不是绝对。
: Restful 的缓存，扩展性，认证，处理大批量数据，里面还是有些门道，可以单独开贴
: 讨论。
: Restful api 我是野路子出身，不怕大家笑话，看了点wiki介绍就开始边学边用，如果
: 哪位可以介绍一些资料，不胜感激。
g*t
65 楼
看书我觉得没用。
热门的领域写书的一般水平都比较低。
各大云的设计guidance等文档一般都是老司机写的。我觉得可以学习。
: 同问：谁能推荐个rest设计的经典书？用了好久，一直没兴趣系统的提高
一下。
【在 g*********9 的大作中提到】
: 同问：谁能推荐个rest设计的经典书？用了好久，一直没兴趣系统的提高一下。
热门的领域写书的一般水平都比较低。
各大云的设计guidance等文档一般都是老司机写的。我觉得可以学习。
: 同问：谁能推荐个rest设计的经典书？用了好久，一直没兴趣系统的提高
一下。
【在 g*********9 的大作中提到】
: 同问：谁能推荐个rest设计的经典书？用了好久，一直没兴趣系统的提高一下。
i*9
66 楼
restful 的东西拿来做演示挺好，一上产品就只能层层加 cache 了，原因就是你说的
，太慢。而且符合规范的GET请求的定义也很 cache 友好。
于是正式发布之后，主要工作就是到处加 hack 和强制 cache flush 来解决各子服务
之间 cache 不一致产生的冲突了。很爽的！
：关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能
只讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
：
，太慢。而且符合规范的GET请求的定义也很 cache 友好。
于是正式发布之后，主要工作就是到处加 hack 和强制 cache flush 来解决各子服务
之间 cache 不一致产生的冲突了。很爽的！
：关于Restful规范，再讲一个自己碰到的比较郁闷的故事，我的总结是，API设计不能
只讲规范，忽略实际情况，要在各方面取得平衡，避免学院派的设计。故事如下：
：
相关阅读
搞docker的别忘了lxc/lxdHow to Search Users within 50 miles away from mehn首页文章，is heron killing storm?app过时了吧 下一波大发展估计是机器人用什么编程?写ruby又中一招为什么在windows 的 c++ ide codeblocks 上装个c++ package 这么麻烦？Palantir靠的是军方关系laptop 可以连到学校的wireless, 但是不能连到家里的，什么原因啊？有啥arm linux可以用的轻量js IDE吗？有什么远程协作的standalone的video 产品么？想转行做马工，要怎么学起阿里系统崩溃，没人讨论下感觉Swift开源后有望到当年visual basic的高度C++ most vexing parse到底怎么回事？Meteor框架的坑有哪些朋友跳了？想山寨palantir了Svn vs git请问MySQL的replication不通过应用程序能达到strong consistenc (转载)发现了一个规律python/javascript有没有一些lib可以比较好的parse pdf文件？