rpplusplus / eyeson Goto Github PK

以下内容由OO和TXX共同完成：

1. 建立数据库
2. 实现将新浪微博、人人网封装到unified-api的逻辑
3. 确定服务器与客户端的通信方式，并实现
4. 实现应用本身的后台逻辑，包括注册登陆、账号绑定、关注对象的逻辑。

以下内容需要注意：

1. 先不做数据分析模块的逻辑, 但设计unified-api接口时尽量考虑到数据分析需要的可扩展性（仅从unified-api作为数据来源的角度来说，这一点应该不难）
2. 先不考虑做客户端用户界面，通信最好直接用命令行测试
3. 先做人人网和新浪微博的API，等架构完善之后再考虑其他平台
4. 我们不做豆瓣平台了

以上有什么遗漏，直接在issue下评论。
OO和TXX注意comment此issue。

系统概念定义文档记录了需要储存在后台数据库中的数据条目, 以及相关说明.

此前我已经把与用户功能有关的数据项填入了此文档.

豆丁需要将与运营数据记录有关的数据项填入此文档, 以便向后台架构和开发明确需求. 这些数据主要用户产品上线后的运营数据收集和分析.

8月18日前完成

明确unified_api的定义，并mock之，搞定unified_api和客户端的通信。

给出后台架构图的设计方案，作为实际开发的依据。

8月19日完成

设计一个猫头鹰形象的图案, 矢量或非矢量均可, 要求:

1. 黑白; 不使用任何半透明效果;
2. 背景透明;
3. 边缘锐利, 不要使用外发光/阴影的效果, 输出之后可以直接用该图案做出添加了外边框之后的满意效果.
4. 图案需要将猫头鹰的特征抽象, 首选特征是眼睛.

该图标的用途:
加工成icon, 用于某些场合的logo, ...

8月26日前完成

刚才跑通了 web客户端的API
然后就有了这么一个问题

咱的架构是：用户手机平台登录，获得session_key，把session_key交给服务器，之后都是服务器来操作，将二次封装的API提供给客户端。

这个架构貌似是被项目定死的，没有办法修改了的...除非能拿到密码登陆的权限。
那么问题就来了：

客户端API调用是使用session_key(没发现是否会过期，可能除非权限变了才需要刷新？)
web端调用是使用access_token(几小时内过期需要重新刷新)

如果用web端去刷手机api 我测试过是没问题的...
只不过...人人会不会ban掉咱的ip？

毕竟手机IP不会出现一小时 成千上万次的访问人人ip... 而且还不断地更改用户....
除非是一个庞大的局域网 都在用这个app.....

那么这个api请求的限制 呢？ 人人根本没有提及

新浪倒是提了...
测试阶段 一小时1k
发布之后 一小时1w..
不过这明显还是不能满足咱的需求的... 这又是个问题...

针对这两个问题 寻求解决方式

可能有必要找人人交涉

明确unified_api的定义，并mock之，搞定unified_api和客户端的通信。

改进两个交互图，让其更接近视觉稿