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