标签:uri 它的 架构 rpc editor span 界面 src code
atitit.基于http json api 接口设计 最佳实践 总结o7
1. 需求:::serverand android 端接口通讯 2
2.3. key,dynami key)韩式 static key? 2
3. 选型大全:rim ,ws, http xml ,json ,RESTful -- RPC ---ws 3
3.2. RPC的长处::与编程语言概念相应 meth(param) 3
4. 从开发速度考虑,单个的url json RPc更加好。。 4
每次都须要trans tok 4
4
5. 公布对外http接口:注冊api接口子方法处理器(服务端) 5
9
9
13. ws---不能同一时候开发。麻烦。基于wsdl工具的没有 9
附加參数说明
參数 |
是否必须 |
说明 |
meth |
是 |
调用的接口方法( 验证,返回设备状态。反馈下载信息,播放流水上传等,各自模块定义) |
Param |
是 |
实际的參数 |
|
|
|
appid |
是 |
|
secret |
是 |
预留,可临时不用。。 用户唯一凭证密钥,即appsecret |
Sign |
是 |
签名 |
Zip |
非 |
实际參数是否压缩 为t显示为压缩状态.. |
Encry
|
非 |
If 加密方式这个是非空的,其它參数不生效..非加密能够空的,其它參数生效 |
accessKey ( dynami key)韩式 static key??
普通的md5 签名已经不安全了.. 比較好的是混合签名法..
使用等级最高的的aes 加密法..
当数据上传量大的时候儿,应该使用压缩
?
应该首先压缩在加密... 中间要是 接收了小,解密,不正确走不须要解压了..
And 加密的时候儿数据也猴..
RPC 样式的 Web 服务client将一个装满数据的信封(包含方法和參数信息)通过 HTTP 发送到server。
server打开信封并使用传入參数运行指定的方法。
方法的结果打包到一个信封并作为响应发回client。
client收到响应并打开信封。每一个对象都有自 己独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务,URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。
在 RPC 样式的架构中。关注点在于方法。而在 REST 样式的架构中,关注点在于资源 —— 将使用标准方法检索并操作信息片段(使用表示的形式)。资源表示形式在表示形式中使用超链接互联。
ws 要同步开发要使用wsdl,可是wsdl可视化工具非常少..麻烦的..
meth。param。tok。
韩式使用req param 做为信封...要是马信封 ,直接post,不好form 提交測试..
http://host/api.jsp?appid=APPID&secret=APPSECRET&submethod=login?m={param1:val1,param2:val2}
作者:: 老哇的爪子 Attilax 艾龙。 EMAIL:1466519819@qq.com
转载请注明来源: http://blog.csdn.net/attilax
基本的加入一行...HandlerChain reg(String subMeth,Handler handler);
HandlerChain.reg("postPlayRec", new HandlerImp1());
HandlerChain.reg("postPlayRec", new Handler() {
@Override public Object handleReq(Object arg) throws Exception {
// attilax 老哇的爪子 is6 o7l
return " o788 test ...";
}
});
导入template。xml模板。
。java>editor>template>>import。。。
输入api 生成一下大陀代码
HandlerChain.reg("postPlayRec", new Handler() {
@Override public Object handleReq(Object arg) throws Exception {
// attilax 老哇的爪子 is6 o7l
return " o788 test ...";
}
});
http://host/api.jsp?appid=APPID&secret=APPSECRET&submethod=login?m={param1:val1,param2:val2}
正常情况下,server会返回下述JSON数据包:
{param1:val1,param2:val2}
參数含义各模块定义。。。
会返回错误码等信息。JSON数据包示比例如以下(该演示样例为AppID无效错误):
{"errcode":40013,"errmsg":"invalid appid" }
每次调用接口时,可能获得正确或错误的返回码, 能够依据返回码信息调试接口。排查错误。
返回码 |
说明 |
-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 |
其它返回码 |
。。 。 。 |
get方式发送參数是须要url编码。
REST (REpresentation State Transfer) 描写叙述了一个架构样式的网络系统,比方 web 应用程序。它首次出如今 2000 年 Roy Fielding 的博士论文中。他是 HTTP 规范的主要编写者之中的一个。
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
---Web 应用程序最重要的 REST 原则是,client和server之间的交互在请求之间是无状态的。从client到server的每一个请求都必须包括理解请求所必需的信息。假设server在请求之间的不论什么时间点 重新启动。client不会得到通知。此外,无状态请求能够由不论什么可用server回答,这十分适合云计算之类的环境。
client能够缓存数据以改进性能。
URI仅仅代表资源的实体,不代表它的形式。
严格地说。有些网址最后的".html"后缀名是不必要的。由于这个后缀名表示格式,属于"表现层"范畴,而 URI应该仅仅代表"资源"的位置。它的详细表现形式,应该在HTTP请求的头信息中用Accept和Content-Type字段指定。这两个字段才是 对"表现层"的描写叙述。
这表示组件无法了解它与之交互的中间层以外的组件。
通过将系统知识限制在单个层,能够限制整个系统的复杂性,促进了底层的独立性。
当 REST 架构的约束条件作为一个总体应用时,将生成一个能够扩展到大量client的应用程序。
它还减少了client和server之间的交互延迟。统一界面简化了整个系统架构。改进了子系统之间交互的可见性。REST 简化了client和server的实现。
由于"资源"表示一种实体。所以应该是名词,URI不应该有动词。动词应该放在HTTP协议中
http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo
由于不同的版本号,能够理解成同一种资源的不同表现形式,所以应该採用同一个URI。版本号号能够在HTTP请求头信息的Accept字段中进行区
要设置一瓦url了..不适合java开发..热部署的问题.
什么是REST?以及RESTful的实现 - 51CTO.COM.htm
atitit.基于http json api 接口设计 最佳实践 总结o7
标签:uri 它的 架构 rpc editor span 界面 src code
原文地址:http://www.cnblogs.com/blfbuaa/p/7078927.html