REST讨论刚要第二版

REST讨论刚要 第二版

一年前，我推出《REST讨论刚要》第一版 。时隔一年以后，随着REST技术的推广，情况发生了变化，有些内容已经有了比较统一的答案，而另外一个内容咋原先的版本中根本没有涉及到，因此在基础进行更新。

 

A、REST是什么，这个问题虽然现在已经讨论过很多，并且多数人都会有比较统一的答案。但是其中很多内容依然还不清晰，比如是关于URI和URL的差异；REST的中的操作和业务操作究竟是什么关系；一个REST框架是应该尽量来以显式方式实现业务操作，还是应该只实现http内在的操作；如此等等。当然这些问题，我不认为有绝对的答案。但是区分其性质和应用的范围，可以让我们在实际的使用中权衡把握。

1、REST的优势是什么，哪些优势更加值得我们去珍惜。这个问题，是目前最迫切需要搞明白的。

2、由上问题的讨论，我们可以产生一个新的疑问——REST的应用究竟是应该全方位的，无所不在的；还是应该受到限制。如果有限制，那么这些限制的权衡条件是什么。

3、紧跟着，由问题2会产生另外一个十分重大，但是几乎还没有什么人意识到的问题——是不是叫REST应用在程序的内部结构和外部接口等所有地方，才是可取的；难道我们仅仅把REST的思想应用在程序直接的交互接口方面，就不行吗？这样做就成本付出如何？

4、而进一步来说，更加重要的一个问题是——当我们在使用REST技术设计我们程序的内部构造的时候，一个资源的究竟在什么粒度上用URI表达更加合适。这个问题同问题3有很多相通的地方。

5、REST的无状态约束下，如果实现状态。可以说随着REST使用的经验增多，对于REST基本理念的认识，带来的问题显得更加重要了。并且这些问题已经不仅仅是理念问题，也可以说很多其实就是一个技术问题和实现的策略问题。

 

B、REST同现在流行技术的关系，这个问题的重要性随着使用的推广有所下降。

1、REST同MVC的关系，我们已经认识到MVC虽然同REST一样可以是程序整体的组织形式，但是MVC更加关注于与显示和界面相关的部分，可以说更加关注程序的层次结构。而REST则更加关注各个模块间的协作问题。而进一步有一个问题，是不是在MVC的层之间，可以使用REST接口的方式进行衔接呢？

2、Rails中对REST的支持策略究竟是一个什么水平，其策略对开发者造成的影响究竟如何。这个方面的讨论在国外已经非常多，并且怨言也非常多。比如Rails的Routes形式，URL的构造形式，Helper的内容形式等等都有所涉及。

3、REST同Ajax的关系。虽然大家认为，Ajax同REST的配合会起到十分好的效果。但是两者并没有内在的必然联系，更不能说REST天生是绑定在Ajax上的。但是正是由此我们可以看出，REST的显示同内容的分离，使Ajax的应用更加可以得心应手，也更加值得我们去在具体的应用中使用。因此这个方面的讨论，已经进入了如果更加有效的使Ajax技术应用到REST风格的框架中去。

4、REST同数据库结构的关系。虽然关系数据库理论的开创者Codd，从一开始就强调数据同应用无关的思想，但是在使用过程中，我们一直受到性能和开发效率以及习惯的影响，从来没有完全实现这个思想。而今即使在REST这个技术中，这样的情况一定也会再次出现。而这里其实涉及一个比较隐晦的问题，那就是我们常用的MVC模式下，M所代表的是对象；而REST则强调的是资源。那么资源同业务对象到底是什么关系，是不是有所区别。而假若有区别，那么使用的ORM方式是不是也该有所不同，数据的存储方式是不是也该有所不同。这个方面讨论的不多，但是今后一定会成为一个比较微妙的讨论点。

5、REST同模板的关系。显然REST技术是同web绑定的，而模板无疑是一种最常见的关联技术。这个方面讨论也不多，但是如果将REST的URI同对象技术比较，就会有许多的地方产生影响。这个地方的讨论，现在也不多，但是并不是说这里不重要，而是说应用的深入程度还没有到达这里。

 

C、支持REST实现的技术手段。

1、Routes技术无疑是首先会被提及的。而这点在国外对Rails在这个方面上的怨言就可以看出来。而Merb的实现思想则显然同Rails不同，也是一个证据。同时其他的几种框架，也都在这个地方有自己的特点。这些方面都需要我们去认识这些框架设计者的最初设计动机进行观察和认识。

2、URI的产生方式。这个方面虽然讨论不多，但是却十分的微妙。考虑到REST更多的时候是用来规定接口，那么其命名规则就是一个问题。同时由于存在一个设计的灵活和自动生成的问题，URI究竟是手动指定，还是自动产生也是一个问题。而如果可以自动生成，那么使用什么方式也是一个问题。

3、URI和URL之间的映射关系，也十分微妙。究竟是直接的一一显式对应，还是通过某种机制间接对应呢？两者的特点是什么，应用范围又如何呢？

 

D、如何将业务映射到REST模型上去。显然一个技术必须要考虑如何同实际的商业应用挂钩，也就是如何使这个技术更好的反应业务关系。

1、资源和业务模型的关系，是不是需要建立一个业务资源模型以替代业务对象模型。

2、如何在需求分析的早期，就有意识的对将来使用REST技术构造程序做准备。

3、在使用REST技术的程序中，应该如何将业务逻辑用组合的形式实现。这个方面现在还没太多的进行过讨论，但是这个方面其实才是REST能否应用于商业应用首先需要解决的问题。

 

E、REST方式下的编码技术。

1、当然是命名约束。

2、REST方式下，自然从构架层面来说，同其他技术会有所不同。那么更加适合REST的技术构成形式是什么样的呢？

3、而进一步，REST构架下，模块的划分原则是什么。

 

F、REST下的测试。

1、如何使用现有的技术对REST程序更好的进行测试。

2、如何设计出更适合REST技术的测试工具和手段。

3、REST的性能测试手段是不是会与其他的性能测试应该有所不同，这一点是几乎还没有有任何的讨论，但是一定会出现的一个重要问题。

 

G、使用REST的团队应该如何适应这个技术。

1、SCM是不是需要做专门的调整。如果需要如何调整。

2、虽然REST的接口更加友好，但是如何控制和把握住还是需要团队内部的磨合。

3、而重构在REST也将会是一个比较微妙的问题，这是由于REST下的接口硬约束必然的后果。

4、在REST下应该如何划分任务，人员分配的策略是不是会有不同。

 

H、REST下的安全问题。这个方面有一些讨论，但是还不多。但是如果REST要普遍被接受，这个问题就显得特别突出了。可以说现在的根本问题还是在REST的基础理念的理解和认识问题，几乎所有的分歧和争论最终都可以归结到对于REST究竟该如何理解这个根本问题上来。