|
锁定老贴子 主题：将sql作为rest资源会产生什么 ?
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2007-05-29
如果将一个复杂的sql查询作为一个资源进行调用rest确实能完成多数web应用
当然这个是否符合rest的资源理念还有待讨论 比如abc.sql 是一个删除过期定单的操作 这个操作将删除远程mysql order表中所有过期的定单 rest直接指向abc.sql而非定单资源 比如 get www.db.cn/sql/abc.sql?usr=***&pwd=*** 这样sql变成了可被rest系统调用的资源(带权限的函数库) 声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
|
| 返回顶楼 | |
|
最后更新时间：2007-05-30
exist支持上面的用法 不过exist是xmldb所以是xquery 不过我想这个在mysql和sql上应该也能实现
昨天工作的太兴奋 没睡好觉 修正一下 rest直接指向abc.sql而非定单资源 比如 get username:password@www.db.cn/sql/abc.sql |
| 返回顶楼 | |
|
最后更新时间：2007-05-30
这得要database支持。本来是用rest模式调用自己的controller，由controller去发送sql，这么干就变成直接把database变成controller了。这可是走回把业务逻辑在database端实现的老路啊。
|
| 返回顶楼 | |
|
最后更新时间：2007-05-30
无明 写道 这得要database支持。本来是用rest模式调用自己的controller，由controller去发送sql，这么干就变成直接把database变成controller了。这可是走回把业务逻辑在database端实现的老路啊。
将需要的sql put 到指定资源即可. database并没有变成controller 仅仅是单纯的数据库 执行sql返回结果. 在rest中没有controller 只有资源和向资源发出的请求. 我好象听说mysql也在开发rest api. 本来想放弃rest :D 结果发现了这个, 这样rest几乎可以完成99.99%的应用了 |
| 返回顶楼 | |
|
最后更新时间：2007-05-30
controller的作用是引入中间层隔离复杂性，这个不管是不是REST架构，都需要的。
比如说，有这么一个场景： 需要从数据库里提前一些数据，然后对这些数据进行计算，如一些较复杂的财务报表或者统计报表。好，这个报表是一个资源，那我们怎么实现它？ 一种做法是用一个controller做为这个报表资源，controller本身发送sql，把基本数据从数据库中取出来，然后在controller中进行计算，把结果返回。 另一种做法就是写一个复杂的sql，直接由database返回结果。这种情况下，sql就是一个资源。 那种方式更好些？我会选择前一种，让database承担太多的计算，不但对于性能有负面影响，而且更多的引入了对数据库的依赖，也把业务逻辑塞到database里去了。 |
| 返回顶楼 | |
|
最后更新时间：2007-05-30
已经有人这样做了。看看这个：http://sqlrest.sourceforge.net/
XML数据库的性能和可伸缩性很成问题，这是短期内难以解决的问题，因为没有可靠的数学模型来支持其达到线性的可伸缩性以及根据这些理论对其存储结构进行优化。而关系数据库是建立在成熟可靠的数学模型之上的，性能和可伸缩性的优势非常明显。 将REST风格的HTTP GET/POST/PUT/DELETE请求直接映射到SQL，是一种过度的简化。必然会导致非常细粒度的API，会对应用的性能和可伸缩性产生很大影响，从而毁掉应用的可用性。任何基于网络的API都应该是粗粒度的，这是一个大的原则，无论这个API是通过SOAP还是通过REST风格的HTTP请求暴露出来的。 客户端越过服务器端的业务对象直接通过REST风格的API与数据库打交道，当遇到较为复杂的需求时，实现起来很不灵活。 例如：假如我做了一个网站联盟，一个网站主用户会有他的网站信息、他的账户信息、与他相关的统计信息等等附带的信息，如果我删除一个网站主用户，肯定要删除掉其连带的信息。按照以上方式做开发，你要么通过数据库触发器来实现（或者通过外键来实现级联的删除），要么通过细粒度的API发送多个HTTP请求（转化为多条SQL语句）来实现，两种方法都不是什么好方法。 另外，还有很多资源并不是与数据库中的表相对应的。资源对应的是一种抽象的概念，你可以把任何抽象的概念定义为一种资源。认为资源与数据库表一一对应的想法是错误的，也限制了对于资源的理解。 |
| 返回顶楼 | |
|
最后更新时间：2007-05-30
无明 写道 controller的作用是引入中间层隔离复杂性，这个不管是不是REST架构，都需要的。
比如说，有这么一个场景： 需要从数据库里提前一些数据，然后对这些数据进行计算，如一些较复杂的财务报表或者统计报表。好，这个报表是一个资源，那我们怎么实现它？ 一种做法是用一个controller做为这个报表资源，controller本身发送sql，把基本数据从数据库中取出来，然后在controller中进行计算，把结果返回。 另一种做法就是写一个复杂的sql，直接由database返回结果。这种情况下，sql就是一个资源。 那种方式更好些？我会选择前一种，让database承担太多的计算，不但对于性能有负面影响，而且更多的引入了对数据库的依赖，也把业务逻辑塞到database里去了。 对数据的计算完全交给数据库当然不好 而且违背设计准则. 如果得到这个报表的原始数据确实需要复杂查询 在xmldb中可以这么实现 get www.xmldb.cn/rest/xquery/excel-a.xql?_xslt=http://www.bslogic.com/xslt/excel-a.xslt 这样复杂计算的任务就交给bslogic了 xmldb只返回原始数据 |
| 返回顶楼 | |
|
最后更新时间：2007-05-30
dlee 写道 将REST风格的HTTP GET/POST/PUT/DELETE请求直接映射到SQL，是一种过度的简化。必然会导致非常细粒度的API，会对应用的性能和可伸缩性产生很大影响，从而毁掉应用的可用性。任何基于网络的API都应该是粗粒度的，这是一个大的原则，无论这个API是通过SOAP还是通过REST风格的HTTP请求暴露出来的。 客户端越过服务器端的业务对象直接通过REST风格的API与数据库打交道，当遇到较为复杂的需求时，实现起来很不灵活。 例如：假如我做了一个网站联盟，一个网站主用户会有他的网站信息、他的账户信息、与他相关的统计信息等等附带的信息，如果我删除一个网站主用户，肯定要删除掉其连带的信息。按照以上方式做开发，你要么通过数据库触发器来实现（或者通过外键来实现级联的删除），要么通过细粒度的API发送多个HTTP请求（转化为多条SQL语句）来实现，两种方法都不是什么好方法。 sql本身也是资源 我用rest的方式将sql文件put到指定位置有何不可 ? 不管sql有多复杂 用一个sql文件总可以了吧. 如果将sql文件当做资源 这个sql文件当然是可以修改的 这应当是相当灵活的方式. |
| 返回顶楼 | |
|
最后更新时间：2007-05-30
to winterwolf：
问题是让客户端的用户理解SQL是一种资源是否合理？用户（可能完全不懂技术）所理解的资源应该是与他要做的事情，就是他所采取的动作直接相关的一种抽象的概念，即使是抽象的概念，也应该让用户非常容易理解。 你这种做法又回到了以SQL为中心的数据建模了，其实是在走回头路，面向对象设计的必要性我就不需要重复了。 |
| 返回顶楼 | |
|
最后更新时间：2007-05-30
不好意思
www.xmldb.cn/rest/xquery/excel-a.xql?_xslt=http://www.bslogic.com/xslt/excel-a.xslt 执行可能还是由xmldb来做的 只是xslt是外部的 如果一定要放到xmldb外边执行还有其它方法 比如用cocoon |
| 返回顶楼 | |
