很久前写的 mongo 的 ORM 后来换工作什么的就再没维护了 orz 不知道楼主觉得我这样的 api 设计的如何 https://github.com/yeyuexia/mongotoy

reduce(lamda x, y: y(x), funcs, data)

@Ouyangan 其实他作为一个规范的最大好处就是前后端配合熟悉了之后，只需要去看 uri 就能知道是在做什么
对于后端开发来说 还有一个好处就是做 restful 设计的时候 你会更多的考虑你数据结构的设计，让数据结构设计更合理。

@edison111cry restful 的前提是一个假定：所有的请求都是在处理资源 ，所以 uri 上都应该是名词，而动作则用 http 的 method 在表示 至于 path 的先后顺序 就有些类似面向对象里面设计的类的层级了
添加比如商品的评论
应该是 goods/comments POST user ， content 信息应该传 body 而不应该放在 path 里面

@Ouyangan
user/insert users POST
user/select users/{id} GET
user/update users/{id} PUT
user/delete users/{id} DLETE
user/list users GET
最基本的东西了 建议先去好好读读 restful 规范吧

@labasq https://dev.mysql.com/doc/refman/5.7/en/view-algorithms.html
顺便楼上没一点干货就在那说别人瞎扯的 啧啧

@labasq 除了不够灵活以外没什么缺点 一般常用的确定的复杂查询都建议用 view 来做的
其实 如果是做报表，为了效率等考虑，又不要求很高的实时性的话，还是建议用异步任务来生成专门的表。毕竟数据量大了之后 join 性能也很让人心碎……

join 查询是最快的……你那种直接作 view 吧……

@Michaelssss xml/json 是做集成测试吧 其实我们做这个工具主要也是为了方便集成测试，因为 unittest 一般不会出现这么复杂的数据结构……
用 xml/json 的好处是直观，传递的数据一目了然，但是也有一个问题就是维护成本很高，如果改动了契约要改很多地方，而且通过 xml/json 构建数据的话，实际上并没有很好的办法知道你的数据哪一些字段是这个测试需要覆盖的关键数据，哪一些其实并不需要，重构测试的时候也会造成很多麻烦

@Michaelssss 233 为什么会被批判没什么卵用呢？

我自己在推广的规范是这样 url 不用驼峰命名 其中 url 的 path 用-号分割单词， queryparam 用_分隔 body 里面的用 field 用驼峰命名。
－分隔的东西在前端没办法很好的写成变量 所以避免了一些直接映射
_分隔的东西可以很好写在 dict 的 key 里 很直观
驼峰的东西就是数据的映射了

习惯之后很直观，一看就知道是在哪用的

试一试吧？

@redhatping 你字典只是引用 不是用 ＝ 赋值 所以地址不变

楼上好多精神老板 233

第二题我没记错的话 list 所占内存每次满的时候扩充一倍

sqrt' :: Double -> Double -> Double -> Double -> Double
sqrt' target buttom top t
| abs (result * result - target) < t * t = result
| result * result - target > 0 = sqrt' target buttom result t
| otherwise = sqrt' target result top t
where result = (buttom + top) / 2

sqrt :: Int -> Double -> Double
sqrt v t = sqrt' (fromIntegral v) 0 (fromIntegral v + 0.25) t

最近刚学 haskell 于是尝试着写了下，写的很难看 献丑了 orz

@rosalindest 在 有事私聊吧 [email protected] 我邮箱

@rosalindest 啥事？

233 这个时候可以推一下我们自己搞的一个基于 jpa 的封装了，大家有兴趣可以来试试嘛. 不过目前该框架只是对 query 进行封装，并不支持 join 查询。
https://github.com/elvis-liu/yaz