Nodejs与rrestjs的相遇，是惊喜，是开始。
Nodejs与rrestjs的相遇，是惊喜，是开始。
开始
rrestjs是我无意中确是有意接触到的一款类似却又不似express的nodejs开发框架。
为什么这么说呢？
因为我在使用express的时候，特别不爽，主要是路由这块，一堆一堆的配置，而且这个配置还是不可控的，怎么说呢。比如：app.get(’/get/:id’, function(){});假如用户访问的地址是：/get/test也将会跑到这块来处理。虽然在express 3.0版本增加了一 >个next方式，让这块处理可以转移到别的路由去处理，但是感觉还是不是很爽。然后开始琢磨是不是有更好的基于nodejs的框架呢。google了一下，然后就发现了rrestjs。
之后就是看里面的例子，发现很不错，试用了一下也非常棒。里面的想法和实现，深深的震撼了我，因为那就是我要找的，而我找到了。
然后毫不留情的说服身边的人，把之前基于express构建的变成基于rrestjs构建的。
事情的开始就是这样子的了。
rrestjs路由
然后，很有必要说说rrestjs的路由。
rrestjs的路由在包裹在try{…}catch(e){}里的一段代码。非常短小，如下：
try{
require('./controller/'+req.path[0])[req.path[1]](req, res);
}
catch(err){
restlog.info(req.path.join('/')+'; '+err);
res.r404();
}
rrestjs在接收http请求时，对url进行了一次分解。比如：http://yansong.me/u/upload => req.path = [‘u’, ‘upload’]; 然后去require(’./controller/u’)之后再去调用里面的upload方法。对应的u.js就应该是这样子的：
// u.js
exports.upload = function(req, res) {
// your code here
};
而如果不存在./controller/u.js或者不存在upload方法时，就会报错，然后自动转向了catch的处理模块。
如果你看过其他后端框架的处理模式，比如：PHP类的框架。你就很能明白这种思想理念所在了，以及它的便捷性了。
后记
说完rrestjs路由，我的主体思想大概就说完了。
非常感谢与rrestjs的作者本人snoopyxdy沟通，中间碰到了很多的一些问题，得以很快解决和理解。
之后打算写一个关于rrestjs路由的改进方案。。。
欢迎来我的github博客yansong.me共同讨论。
Nodejs与rrestjs的相遇，是惊喜，是开始
开始
rrestjs是我无意中确是有意接触到的一款类似却又不似express的Node.js开发框架。
为什么这么说呢？
因为我一直在使用Express，但特别不爽的是路由部分的配置。一大堆的路由配置显得不够灵活，且难以控制。举个例子，比如你有这样一个路由配置：
app.get('/get/:id', function(req, res) {
// 处理逻辑
});
如果用户访问的是 /get/test，也会被这个路由匹配到，尽管 test 并不是一个有效的 id。虽然在Express 3.0版本中引入了next 方法，可以将控制权转移给下一个匹配的路由，但这仍然感觉不够优雅。
于是，我开始寻找是否有更好的Node.js框架。经过一番搜索，我发现了rrestjs。
rrestjs路由
rrestjs的路由设计给我留下了深刻的印象。它的路由机制非常简洁，封装在一个try...catch块中：
try {
require('./controller/' + req.path[0])[req.path[1]](req, res);
} catch (err) {
restlog.info(req.path.join('/') + '; ' + err);
res.r404();
}
rrestjs在接收到HTTP请求时，会先解析URL路径，并将其分解成数组形式。例如，对于请求 http://yansong.me/u/upload，req.path 会被解析为 ['u', 'upload']。接下来，它会尝试加载 ./controller/u.js 文件，并调用其中的 upload 方法。
假设 u.js 文件的内容如下：
// u.js
exports.upload = function(req, res) {
// 处理逻辑
};
如果 ./controller/u.js 不存在，或者 upload 方法不存在，那么会抛出异常，进而进入 catch 块，返回404错误。
这种设计理念类似于一些PHP框架中的处理方式，使得路由管理和控制器分离更加清晰，同时提高了代码的可维护性和扩展性。
后记
通过与rrestjs的作者snoopyxdy的沟通，我解决了许多遇到的问题，并对其有了更深入的理解。未来我还计划编写一篇关于如何改进rrestjs路由的文章。
非常感谢rrestjs的作者，同时也欢迎大家来到我的GitHub博客yansong.me共同探讨Node.js的更多可能性。
以上内容展示了Node.js与rrestjs相遇的旅程，从最初的不爽到最终找到满意的解决方案。希望这段经历能给正在寻找更好Node.js框架的开发者带来启示。
自己也尝试的做过路由解析，还算比较简单，但是老吴把很多东西都做了封装改进，效果比我的那个好很多。自己还做过类似java的package机制，书写比较简单，可是没多大意义。3月份用的老吴的框架，后来改成自己的框架，再后来觉得老吴的框架确实很不错，又切回去了，哈哈，老吴大神。。。。
没错，链式处理很灵活 即使不想使用next(‘route’) 也可以通过将需要单独处理的router前置解决，无非是个代码组织加载的问题 个人感觉try catch 也没有errhandler来的优雅~
express其实可以配置的
app.all('*', function (req, res, next) {
var path = req.path.split('/');
try{
var route = require('./controller/'+path[1]);
var fn = route[req.path[1]];
fn(req, res);
}
catch(err){
next();
}
});
Node.js 与 rrestjs 的相遇，是惊喜，是开始
开始
rrestjs 是我无意中发现的一款基于 Node.js 的开发框架，它不同于传统的 Express 框架。我在使用 Express 时，发现其路由配置繁琐且不够灵活。例如：
app.get('/get/:id', function() {});
用户访问 /get/test 也会被这个路由匹配到，尽管这并不是我们想要的结果。虽然 Express 3.0 版本引入了 next 方法，但依然觉得不够完美。于是开始寻找更好的替代方案，最终发现了 rrestjs。
rrestjs 路由
rrestjs 的路由机制非常独特。它将路由处理逻辑封装在一个 try...catch 块中，具体如下：
try {
require('./controller/' + req.path[0])[req.path[1]](req, res);
} catch (err) {
restlog.info(req.path.join('/') + '; ' + err);
res.r404();
}
rrestjs 在接收到 HTTP 请求时，会将 URL 进行分解。例如：
http://yansong.me/u/upload
会被解析为：
req.path = ['u', 'upload'];
然后 rrestjs 会尝试加载 ./controller/u.js 文件，并调用其中的 upload 方法。假设 u.js 文件内容如下：
// u.js
exports.upload = function(req, res) {
// 处理逻辑
};
如果找不到对应的文件或方法，则会抛出错误，触发 catch 块中的处理逻辑，返回 404 错误。
后记
通过 rrestjs 的路由机制，我发现其设计更加简洁高效，尤其是对于那些需要处理大量 URL 的应用来说，其灵活性和可维护性都得到了显著提升。感谢 rrestjs 的作者 snoopyxdy 提供的帮助，使得我在遇到问题时能够快速解决并深入理解框架的工作原理。
希望这篇文章能帮助更多开发者了解并使用 rrestjs。欢迎大家在我的 GitHub 博客 http://yansong.me 上进行讨论和交流。
