Rop是参照淘宝开发平台（TOP：Taobal Open Platform）实现的全功能Rest Web Service 全功能（Full-Stack）开源框架。它解决了以下的Web Service开发问题：

  1.契约优先，URL完全Rest风格

   Rop(Rest Open Platfrom)是“契约优先”的Rest URL的Web Service框架，主URL固定，通过method=<methodName>参数指定调用方法，调用方法通过@ApiMethod(<methodName>)在Bean上；

[six-ze=large]  2.支持JAXB注解,支持XML/JSON输入、输出 [/size]

  Rop的请求和响应都支持使用JAXB（JSR-222）注解，可以通过format请求指定xml或json,实现请求响应数据绑定和数据输出的完全透明化；

  3.建立错误处理模型，有力降低错误处理难度

   建立了一个可扩展的错误处理模型（这个主要归功于TOP的成熟模型），写Web Service一定要关注服务发生错误时如何返回响应，以便客户端据此做出相应的处理。个人认为，这是Web Service开发最关键的点之一。可以一般的Web Service开发框架由于是纯技术框架，根本没有涉及这个应用型领域的问题，因此造成了大量的甚至是混乱的Web Service开发。Rop已经建立了Web Service的错误模型，一般错误（如数据校验，签名验证，会话验证，安全控制等）Rop框架自动处理，业务错误开发者根据错误模型扩展。
   使用了Rop框架，你的服务错误都可以通过响应报文描述，有力保证Web Service的开发质量和效率。

  4.支持JSR 303标准校验，数据校验极致简化

   请求对象只要打上JSR 303的注解，所有余下的事情（数据校验、错误输出）都由Rop完成，极大降低了Web Service开发的难度。（也许Web页面应用可以只做客户端校验，但是Web Service一定要做服务端校验，且发生错误，必须通过响应报文描述了错误）

5.组件可定制，可扩展：

    既可通过RopServlet的Servlet初始化参数指定组件，也可以在Spring窗口中配置组件Bean(Rop 将自动扫描组件并装配之）。目前支持以下组件：
    1）SessionChecker：会话检查组件，大多数服务方法都必须在会话环境下进行，使用该组件判断请求会话的合法性；
    2）AppSecretManager：应用密钥管理组件，使用Rop开发的开放平台服务，客户端可以开发很多应用，每个应用都必须分配一个appKey,每个appKey对应一个密钥。因此服务端必须能存储并管理这个appKey/密钥对，以便在签名验证时使用。你既可以将appKey/密钥放在数据库中，也可以放到文件中，也可以放在LDAP中，只要相应实现AppSecretManager即可。
    3）SecurityManager：服务安全检查组件，一个请求是否可以执行目标服务，需要很多条件，可以装配该组件以植入安全校验的逻辑。
  
6.支持拦截器

  可以通过RopServlet的Servlet参数指定拦截器（多个逗号分隔），也可以在[/size]Spring容器中配置拦截器，Rop会自动扫描并装配。
   拦截器将在服务调用前及响应返回前调用，可以使用拦截器做日志记录、服务时间审计等很多的事情。可配置多个拦截器，且可以指定拦截器的先后顺序。
 

强烈支持

支持，问个问题，如果CreateUserResponse 调用业务逻辑返回的是一个list，Map，set类型，是不是还的把集合类型的数据遍历取出来，然后再次set进CreateUserResponse呢？

非常强列地支持

这个我先测试一下，应该没有问题的，我的底层是基于JXAB，只要JXAB能够支持，Rop肯定就可以支持的。

支持呀，强烈支持

支持啊！强烈支持

学习~！！开源的~~！！

观察中

最近在项目中使用了Rop框架，效果非常好，特别对服务异常体系规范、同时支持XML及JSON格式、安全的拦截机制等，大大提高了开发效率！但也发现在一些不足的地方：

1. 对输出格式绑定太死，虽然在大多数的应用中，输出XML、JSON格式足够用了。但不能限制用户选择其它输出格式，如输出图片、EXCEL等，至少要提供一个输出格式的扩展机制。像Jersey框架在这方面做得就比较好，任何格式都可以输出。

2. 对REST的服务接口入参及返回参数做了限制，目前只能是RopRequest、RopResponse子类。这样做虽然简单，但大大制约其灵活性。使用起来感觉特别不便。实际的应用过程中，接口的入参是多种多样的，有可能是一个参数、二两参数、N个参数，难道我每一种情况都要写一个类吗？

3. 对REST的URL中，只能使用xxx?method=xxx ,如果method可以让使用者修改，那就更好了。

4. 对输出XML格式时，需要对RopResponse的子类手工编写JAXB相关注解，对于输出复杂的XML格式时，这个过程非常繁锁，且容易出错。 如果能够封装一个根据XSD结构自动生成JAVA类，那使用起来就方便多。目前JAXB就有提供这样的小工具，如果能在这个小工具上做一个批处理工具，那就更完美了。

5. 缺少一个对服务容器的管理，如支持动态发布的服务、撤销服务、获取服务的注册表机制等。这对于一些要求扩展性比较高的应用来讲非常重要。在使用ROP框架中，也认真研究了这个框架，觉得提供这样的功能，应该是比较容易实现，不知作者是否有其它方面的考虑？？？


6. 如果能对输出格式接口RopResponseMarshaller进行重构，并对RopResponseMarshaller实现类进行动态注入，这样使用者就可以编写个性化的输出格式转换器。

7. 希望能够提供一个获取HttpServletRequest方法。虽然一般情况下，很少使用到HttpServletRequest。但有些特殊的场景，如果需要用，但又无法获取，这时真是会让人抓狂！！！