Nov
27
mmsdk: 微信公众平台SDK - php版
昨天关注了下 微信公众平台,的确是个好东西,赞一下tx近来的开放。
它的api 乍一看还是挺简单的,于是就写了个小东西玩玩。
但是在开发的过程中遇到了多个坑,通过有故事王国的@ctqmumu同学把问题转了过去。实际开发的过程中遇到了好几个问题,但是其他问题(包括发一条消息请求我两次)都莫名其妙消失了,只有一个问题(具体见后文)通过被喷的方式解决了。
总之最后是可以用了,于是多花了点时间,把代码完善了下,写好了注释和样例,放在了Google Code上面,有需要的同学可以拿去用。
下载地址:http://code.google.com/p/mmsdk/downloads/list
注:目前callback url仅支持80端口(@2012.11.27)
#UPDATE 2012.11.29 添加了对图片消息的支持(样例)、对调试的支持(DUMP请求/回复的xml文件),测试SAE可用(调试功能除外)
== 分割线,下面是纯吐槽 ==
=== 首先是态度问题。
他们没有sdk。
他们只有一页不那么详细的说明文档,和一个能运行的demo。
他们也没有技术支持,只有一个开发者交流群,里头有一个不说话的pm,和一群偶尔各说各话的开发者。
幸好里面还有一些热心的朋友。
=== 其次是接口问题。
这个接口真是烂得可以。
0. 知道程序员最讨厌的两件事是什么吗?
A:写文档 B:别人的代码没文档。
被喷的问题,是接口里的fromUser和toUser的问题。请求和回复的xml里头都有这两个字段,请求的fromUser应当是回复的toUser。文档没有任何说明(demo有具体实现,没有细看是我的问题)。但是这个接口有必要给两个user么?给用户的id不就够了吗?
1. 接口是同步的。
平台POST请求过来,然后等待我回复数据。同步的确是使得api更简单了,但是也带来的其他问题。对于开发者,我不知道我的数据是不是被正确接收了。如果不是,我没有任何地方可以查到为什么错了(如果是异步的话,可以检查后返回状态码)。对于平台,如果开发者处理慢了,平台需要等待,会导致吞吐量下降。
2. 签名校验几乎白做了。
接口里的签名,仅针对POST请求url里的三个参数签名,完全不管POST过来的xml。同样的,对于api的回复,平台也不做任何验证。也就是说,只要有一个中间人,伪造数据太容易了。反正只要post过来的url不变,请求和回复随便编。
3. 其他各种奇怪。
除了前面提到的fromUser/toUser之外:
A. 只有userId没有userName,而很多微信用户其实没有设置id,微信默认的id可能是类似于 "ogALVjjZmS3X8rHEmd4”,也就是说,开发者只能用来标识,不能用到回复里。 [UPDATE: 这个userId实际上是fakeid,坑爹啊]
B. 用户关注的时候,会发送一个消息过来。这个消息和用户发送一条"Hello2BizUser"的效果是一样的,无法区分(除非你再开个kv数据记录这个用户是不是第一次关注)。
C. 接口用的是xml格式,里头的数据只是简单用 <!CDATA[xxx]]> 这样的方式包起来。如果用户发送个 "]]>",收到的xml文档就没法解析了。顺便提一下,其他开放平台的接口,通常同时提供xml和json格式。
=== 总结:很难想象微信居然发布了这样的一个api出来,步子大了容易扯着蛋啊。
转载请注明出自 ,如是转载文则注明原出处,谢谢:)
RSS订阅地址: https://www.felix021.com/blog/feed.php 。
它的api 乍一看还是挺简单的,于是就写了个小东西玩玩。
但是在开发的过程中遇到了多个坑,通过有故事王国的@ctqmumu同学把问题转了过去。实际开发的过程中遇到了好几个问题,但是其他问题(包括发一条消息请求我两次)都莫名其妙消失了,只有一个问题(具体见后文)通过被喷的方式解决了。
总之最后是可以用了,于是多花了点时间,把代码完善了下,写好了注释和样例,放在了Google Code上面,有需要的同学可以拿去用。
下载地址:http://code.google.com/p/mmsdk/downloads/list
注:目前callback url仅支持80端口(@2012.11.27)
#UPDATE 2012.11.29 添加了对图片消息的支持(样例)、对调试的支持(DUMP请求/回复的xml文件),测试SAE可用(调试功能除外)
== 分割线,下面是纯吐槽 ==
=== 首先是态度问题。
他们没有sdk。
他们只有一页不那么详细的说明文档,和一个能运行的demo。
他们也没有技术支持,只有一个开发者交流群,里头有一个不说话的pm,和一群偶尔各说各话的开发者。
幸好里面还有一些热心的朋友。
=== 其次是接口问题。
这个接口真是烂得可以。
0. 知道程序员最讨厌的两件事是什么吗?
A:写文档 B:别人的代码没文档。
被喷的问题,是接口里的fromUser和toUser的问题。请求和回复的xml里头都有这两个字段,请求的fromUser应当是回复的toUser。文档没有任何说明(demo有具体实现,没有细看是我的问题)。但是这个接口有必要给两个user么?给用户的id不就够了吗?
1. 接口是同步的。
平台POST请求过来,然后等待我回复数据。同步的确是使得api更简单了,但是也带来的其他问题。对于开发者,我不知道我的数据是不是被正确接收了。如果不是,我没有任何地方可以查到为什么错了(如果是异步的话,可以检查后返回状态码)。对于平台,如果开发者处理慢了,平台需要等待,会导致吞吐量下降。
2. 签名校验几乎白做了。
接口里的签名,仅针对POST请求url里的三个参数签名,完全不管POST过来的xml。同样的,对于api的回复,平台也不做任何验证。也就是说,只要有一个中间人,伪造数据太容易了。反正只要post过来的url不变,请求和回复随便编。
3. 其他各种奇怪。
除了前面提到的fromUser/toUser之外:
A. 只有userId没有userName,而很多微信用户其实没有设置id,微信默认的id可能是类似于 "ogALVjjZmS3X8rHEmd4”,也就是说,开发者只能用来标识,不能用到回复里。 [UPDATE: 这个userId实际上是fakeid,坑爹啊]
B. 用户关注的时候,会发送一个消息过来。这个消息和用户发送一条"Hello2BizUser"的效果是一样的,无法区分(除非你再开个kv数据记录这个用户是不是第一次关注)。
C. 接口用的是xml格式,里头的数据只是简单用 <!CDATA[xxx]]> 这样的方式包起来。如果用户发送个 "]]>",收到的xml文档就没法解析了。顺便提一下,其他开放平台的接口,通常同时提供xml和json格式。
=== 总结:很难想象微信居然发布了这样的一个api出来,步子大了容易扯着蛋啊。
欢迎扫码关注:
转载请注明出自 ,如是转载文则注明原出处,谢谢:)
RSS订阅地址: https://www.felix021.com/blog/feed.php 。