atitit.基于httpjsonapi量化接口,接口设计最佳实践总结o7
需求:::服务器andandroid端量化接口,接口通讯
量化接口,接口开发的要点
普通参数meth,param,
所有的参数定义
附加参数说明
| 参数 | 是否必须 | 说明 |
| meth | 是 | 调用的量化接口,接口方法（ 验证，返回设备状态，反馈下载信息，播放流水上传等，各自模块定义） |
| Param | 是 | 实际的参数 |
|
|
|
|
| appid | 是 |
|
| secret | 是 | 预留，可暂时不用。。 用户唯一凭证密钥，即appsecret |
| Sign | 是 | 签名 |
| Zip | 非 | 实际参数是否压缩 为t显示为压缩状态.. |
|
Encry
| 非 | If 加密方式这个是非空的,其他参数不生效..非加密可以空的,其他参数生效 |
防篡改sign
普通的md5签名已经不安全了..比较好的是混合签名法..
使用等级最高的的aes加密法..
当数据上传量大的时候儿,应该使用压缩
首先压缩韩式加密???
应该首先压缩在加密...中间要是接收了小,解密,不对走不需要解压了..
And加密的时候儿数据也猴..
选型大全:rim,ws,httpxml,json,RESTful--RPC---ws
RPC样式/REST样式
RPC样式的Web服务客户端将一个装满数据的信封通过HTTP发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法以及仅公开一个URI的RPC样式Web服务，URI表示单个端点。它忽略HTTP的大部分特性且仅支持POST方法。
在RPC样式的架构中，关注点在于方法，而在REST样式的架构中，关注点在于资源——将使用标准方法检索并操作信息片段。资源表示形式在表示形式中使用超链接互联。
RPC的优点：：与编程语言概念对应meth(para
从开发速度考虑，单个的urljsonRPc更加好。。
json可以同步开发
ws要同步开发要使用wsdl,但是wsdl可视化工具很少..麻烦的..
需要传递的参数使用无状态。。每次都需要transtok
meth，param，tok，
概念简单.走十meth(par
要不要信封???
韩式使用reqparam做为信封...要是马信封,直接post,不好form提交测试..
http://host/apjsp？appid=APPID&secret=APPSECRET&submethod=login¶m={param1:val1,param2:val2}
发布对外http量化接口,接口：注册api量化接口,接口子方法处理器
使用实现类的方法注册..
使用闭包的方式注册:::
//attilax老哇的爪子is6o7l
});
导入template。xml模板。。java>editor>template>>import。。。
输入api生成一下大陀代码
//attilax老哇的爪子is6o7l
});
客户端调用量化接口,接口overview
http://host/apjsp？appid=APPID&secret=APPSECRET&submethod=login¶m={param1:val1,param2:val2}
请求返回说明
正常情况下，服务器会返回下述JSON数据包：
参数含义各模块定义。。。
错误时返回
会返回错误码等信息，JSON数据包示例如下:
{'errcode':40013,'errmsg':'invalidappid'}
全局返回码说明如下：
每次调用量化接口,接口时，可能获得正确或错误的返回码，可以根据返回码信息调试量化接口,接口，排查错误。
| 返回码 | 说明 |
| -1 | 系统繁忙 |
| 0 | 请求成功 |
| 40002 | 不合法的凭证类型 |
| 40008 | 不合法的消息类型 |
| 40013 | 不合法的APPID |
| 40021 | 不合法的版本号 |
| 40033 | 不合法的请求字符，不能包含uxxxx格式的字符 |
| 40035 | 不合法的参数 |
| 40038 | 不合法的请求格式 |
| 40039 | 不合法的URL长度 |
| 40050 | 不合法的分组id |
| 40051 | 分组名字不合法 |
| 41001 | 缺少参数 |
| 42001 | 超时 |
| 43001 | 需要GET请求 |
| 43002 | 需要POST请求 |
| 43003 | 需要HTTPS请求 |
| 44002 | POST的数据包为空 |
| 45009 | 量化接口,接口调用超过限制 |
| 45015 | 回复时间超过限制 |
| 46001 | 不存在媒体数据 |
| 46004 | 不存在的用户 |
| 47001 | 解析JSON/XML内容错误 |
| 48001 | api功能未授权 |
| 50001 | 用户未授权该api |
| 其他返回码 | 。。。。 |
QA：：
get方式发送参数是需要url编码。
0.什么是REST？
REST(REpresentationStateTransfer)描述了一个架构样式的网络系统，比如web应用程序。它首次出现在2000年RoyFielding的博士论文中，他是HTTP规范的主要编写者之REST指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。
0.无状态：：：-
---Web应用程序最重要的REST原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的'.html'后缀名是不必要的，因为这个后缀名表示格式，属于'表现层'范畴，而URI应该只代表'资源'的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对'表现层'的描述。
0.另一个重要的REST原则是分层系统，
这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层，可以限制整个系统的复杂性，促进了底层的独立性。
当REST架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST简化了客户端和服务器的实现。
RESTful架构有一些典型的设计误区。
最常见的一种设计错误，就是URI包含动词。
因为'资源'表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中
另一个设计误区，就是在URI中加入版本号：
因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区
restful的缺点：frag
要设置一瓦url了..不适合java开发..热部署的问题.
ws---不能同时开发，麻烦，基于wsdl工具的没有
参考
文章为作者独立观点，不代表 股票程序化软件自动交易接口观点
相关文章
股民评论