@rming 哇，这个我还不是很了解，需要再看看你做的东西

关于我现在的这家公司，主要是做 wifi 芯片为主，出货量很大，资金流充足，慢慢切入 IOT 领域，这个平台已经在一些情景上得到应用。

stand alone方式需要源码方式在运行在系统上(play run)
按理来说 java 运行的时候不需要源代码的

ssh的话按理是更快的，ssh -vvv 分析一下，大概在两个常见问题上，dns和加密方法尝试

@darkbill 已经回复，非常感谢，iot 在工业能做很多事情，但 tcp/ip 协议看起来“还不够稳健”

zigbee，contiki 这些都非常底层啊，我们主要是 wifi芯片，也有自己的嵌入式 sdk，但这个平台本身，是在这些底层之上的，只要遵循 tcp/ip，底层用什么都可以的，所以是 PaaS 平台。

@lanceli 是的，我们在张江有办公地点，需要 前端、设计... 各种多面手
所以各位，跪求扩散 :-)

@flynngao 这个概念其实很久了，但是一直没有声音，我对各种概念也是不屑一顾的，只是确实可以做出有用的东西，比如：远程开关，定时开启电器，查看家庭用电量等等，另外一些就是工业级别的了。

以我有限的经历看：
1 智能手机非常普及。
2 wifi芯片价格会越来越低。
3 当成本非常低的时候，就有需要的人了。举个例子，带有远程控制的智能插座如果只比传统插座贵5元，那你会不会尝试买呢？

这个平台可以说是物联网，也可以简单说是数据的汇总和展示，另一个重要的功能就是反向控制。

@lanceli 当然是 w ，需要全职，以后开发需要的其他资源可以让其他人协同，我认为没有全心放入的话是不能做好事情的，类似这种项目对技术的要求比较高。

@tuteng 你是说后台技术吗？我擅长使用 java， python，你的技术背景是？
@missdeer 域名这个问题是暂时的，以后估计会使用独立域名的。

@0x61 是的，同样的做法，微信这一点不难的，主要做一个完善的平台有很多事情要做

@kstsca 支付宝只是工商银行的“大账户”，最后总是会进行结算和审核，和银行之间行为一样的，哪有可能凭空变多或者变少。像这样的一些常识怎么总是有人不懂呢。

智商税

@guitarkitten 二分法用递归就是效率不高啊

一一回应：
1 get, post, put, delete 方法的细化，可以很容易在上层做权限拦截，从读取，新建，修改，删除层次上就做到了，当然这个是对方法的使用比较严格。
对于一般的资源，比如 /v1/user/1/ (几个方法表示获取，创建，修改，删除)，如果用你现在的方法，那要怎么表示，无论如何都会很冗余。
rest 是为了描述通用资源的管理，如果你抽象得好，绝大多数请求都是可以归类出来的。其他的你可以自行实现，比如你说的「传统」的 API 设计...
2 从 URL 和 Header 里分离参数是有特别意义的，比如 https://developer.github.com/v3/#authentication，用户认证的 Token 必须放到 Header，如果你放在 URL 里，这是一种不安全的方法。总之，敏感信息是不能带在 URL 上面的，类似 Token，sessionid，Header 是最好的选择。
3 Status Code的细分，你看看下面的描述，你觉得这些没有用的？
200: 正常，可能附带数据
201: 需要创建的对象已经存在
400: 请求参数或者格式不对
403: 没有相关的权限
404: 资源没有找到
500: 内部数据出现错误

总结：
大部分的麻烦，要考虑是不是代码写得不对，因为 rest 的这种规范，代码其实更好写的，以 java 为例子，非常好做继承和复用，统一的错误和异常处理，比如一旦 403 转到权限不足提示页面。

这个地方要看你对缓存怎么定义，对于使用数据库 select * from xx where id = yy 的情况，其实走的大部分也是数据库的缓存，要理解缓存的重要意义，在于访问时间数量级别的差异：比如寄存器，内存，硬盘，网络访问时间...你可以看到访问时间是数量级别的差距，这就是推崇缓存的意义。

缓存遇到的问题是：
1 粒度
粒度太小，增加了维护上的难度，粒度太大，更新频繁，内存占用大
2 副本
缓存是数据库的一个副本，只要存在副本，就存在不一致性的问题，举个例子，有人手工用 sql 语句更新某个值，而缓存是没办法通知到的。副本状态维护在计算机的各种设计上都是很大的问题，从设计上要减少副本。
3 更新机制
和 2 是相关的，没有一种很好的更新机制能非常好的把更新推送到 cache，代码会比较 dirty。

但是依然推崇缓存：
1 例子：mysql 的协议就比 memcached 复杂很多，相对来说在协议上就体现出延时。
2 大幅的减少 db 的压力，以我经验看，大部分程序员很容易把压力扔向 db，然后由数据库管理员负责，这是不对的。

缓存使用原则：
1 不要手工去维护缓存，特别是业务代码里，这是灾难。
2 orm 里面去维护缓存，做各种更新触发操作，对数据的操作只能通过统一 orm。

这个倒是蛮容易的，使用 ssh 公钥密钥，无密码认证，然后脚本读写，so easy

必须开启，因为很多服务会开放端口，但是这个端口对外界是没有意思的，举个例子，如果你启用了 mysql，通过 3306 端口的，请问你要开放 3306 端口出去吗？