如题, 最近打算写一个这样的服务, 把之前的一些 C 库以 RESTful API 的形式暴露出来供外部调用(目前暂时只考虑内部其他系统的访问), 请教做过类似工作的同学几个问题:
除了基本的功能外, 还有哪些坑需要设计的时候注意的? 高并发? 可靠性? 检测恶意输入?
测试的话有哪些边缘测试用例可以检验服务是不是健壮呢?
因为要根据用户的输入提供响应, 而用户的输入有可能很长, 所以考虑用 POST 把输入的字符串放到 body 里, 因为 GET 的 URL 后面参数太长的话可能会有问题? 但唯一一点顾虑是我这个服务其实没有改变服务器状态, 用 POST 感觉有点怪, 不知大家怎么看.
谢谢.
 |
1
fovecifer Mar 25, 2017
为什么不用 C 直接写 REST 服务？这样效率会更高
另外在 REST 中 POST 的语义不是改变服务器的状态吧？建议 LZ 多参考一些优秀的 RESTful API 设计 |
 |
2
taozhijiangscu Mar 25, 2017
大量使用 POST 就违背了 RESTful 的初衷了……
|
 |
3
eyp82 OP @taozhijiangscu 谢谢, 请问为什么这么说?
主要是因为用户要提交的输入可能很长, 用 GET 放到 URL 里感觉可能碰到长度限制吧, 另外好像 GET 里也不推荐用 body? |
 |
4
banpotinke Mar 26, 2017 via Android
同问为什么
|
 |
5
lecher Mar 26, 2017  1
内部系统的话别管那么多规范了，先跑起来服务就可以。
检测恶意参数是优先级最高的，不要相信任何客户端传过来的数据，所有参数都必须校验。是否考虑异步要看提供的服务是不是延时很高的，如果一个正常请求可能要几秒才能把处理好的数据返回，就需要考虑用异步框架在前面把请求都接住。后端开多台服务器提高负载能力，如果只是普通的业务，什么开发快用什么就好。 测试的时候，有时间做边缘数据测试最好，要不至少也得在开发的时候考虑用户有没有可能传负数之类的数据，如果没有那么多时间，可以在编写代码的时候就采取防御式编程作为 RESTful 接口的策略。 如果请求参数已经可能超过 GET 的限制，要放到 POST 里面做，那就不太符合 RESTful 的接口语义，等于应该分在 GET 和 POST 的资源操作都被合并到 POST 里面了，会导致你可能需要在 URL 上面做区分。 比如 /source 是资源的 URL ，按 RESTful 的语义， GET 是获取 /source 的数据， POST 是新增 /source 的数据，你都合并到 POST 接口，可能就要在 URL 上面做区分，/getsource /newsource 这样才能实现资源的区分度。 如果存在这种可能，或许不使用 RESTful 比较好，就在 URL 上面做语义区分。毕竟先提供服务才是主要的任务。能保证某些接口的幂等性就能少掉很多网络延迟导致的异常。 |
 |
8
mooncakejs Mar 26, 2017 via iPhone
内部 restful 不如 rpc
|
 |
9
Lispre Mar 26, 2017
非常不建议这么做
建议采用内部走消息总线的 RPC 形式 |
 |
10
nthhdy Mar 26, 2017
get 也可以有 body 的.
读 elasticsearch 的文档时才意识到这一点. elasticsearch 的许多 api,都是 get 带 body 这样用的. |
|
11
eyp82 OP |
Select Language