你会如何去创建一个使用流星RESTful Web服务。 我想创建Appcelerator的应用程序挂钩到相同的后端。
流星能解决这个问题吗?
你会如何去创建一个使用流星RESTful Web服务。 我想创建Appcelerator的应用程序挂钩到相同的后端。
流星能解决这个问题吗?
我想你可能会创建一个使用流星RESTful服务,但它不是真的什么框架是为 - 流星的主要好处之一是在客户端和服务器之间紧密的相互作用,以及Web服务没有一个客户端。 我建议你寻找到既写一个Web服务后端在自己的或类似的node.js https://github.com/intridea/grape如果你喜欢红宝石。
我在Meteorpedia做了全面的写上这样的:
http://www.meteorpedia.com/read/REST_API
帖子评论所有6个选项用于创建REST接口,从最高水平(例如用于处理你的一切智能的包)到最低水平(如编写自己的connectHandler)。
此外,该帖子的时候使用REST接口是正确的还是错误的事情流星做封面,引用流星REST测试工具,并解释类似CORS安全问题常见的陷阱。
我本来回答了这个问题在这里 ,但回顾一下:
有关数据的顶部添加RESTful的方法,看看能否流星写的收集API:
https://github.com/crazytoad/meteor-collectionapi
至于访问的数据库验证,看看这个项目:
https://github.com/meteor/meteor/wiki/Getting-started-with-Auth
两者都是发展绝对婴儿,但是你可以创建一个RESTful API,它与移动本地客户端很容易地集成。
I know this is an old thread, but in case anyone stumbles across it, I published a package for writing REST APIs in Meteor 0.9.0+:
https://github.com/kahmali/meteor-restivus
It was inspired by RestStop2 and built with Iron Router's server-side routing. In my not-so-humble opinion, it's a better solution than anything posted here thus far.
UPDATE: To clarify why I think it's a "better" solution than those mentioned, I'll just point out the differences between each:
CollectionAPI:
CollectionAPI is limited to exposing very basic CRUD operations on your collections. For my use, which is consuming the REST API in mobile apps, it can be extremely wasteful to send down entire documents, and most of the time I need to do some additional processing of data (for instance, sending a Google Cloud Message in a REST endpoint for adding a friend, but only if the friend is successfully added). CollectionAPI gives you a hook that runs before the endpoint is executed, but from what I understand there is nothing immediately before the response, so you have no way of modifying the data that is returned. For authentication, CollectionAPI allows you to define an authToken that must be passed with each request. This acts more like a traditional api key, as it appears to be hard-coded into your app, and would therefore be the same for every user.
Restivus, since it is not limited to automated work on collections, gives you complete control over your endpoints. It now provides all the functionality included in Collection API. It supports user authentication and role permissions as well, so you can identify the user making the request (and easily access that user from within authenticated endpoints). It provides a login and logout endpoint as well to assist with that. I will provide a code example for Restivus at the end.
HTTP.publish:
From what I understand, this is similar to CollectionAPI in that it is limited to exposing basic CRUD operations on collections. This one is more specifically tied to Meteor's publishing, and allows you use a publish function for handling GET requests. I'm confused by the documentation, but it may or may not have some basic authentication available. I haven't used this before, but I'm not a big fan of the API for it, which feels a bit clunky. Once I'm publishing more extensively I'll try to revisit it. The same team has another package called HTTP.methods which doesn't give you the access to the publish functions, but has a similar api to Restivus and, at the time, similar functionality.
Restivus is "better" because it doesn't limit you to using your publish functions, and therefore allows for a much finer-grained control over your endpoints. If you are just looking to expose your publish functions to an external API, I would recommend you stick with HTTP.publish. Restivus also has a simpler API and supports the HTTP PATCH method (which no other package seems to acknowledge exists). Their HTTP.methods package is pretty similar to Restivus, except it lacks PATCH support, and although it offers some basic authentication, I believe you only have the ability to make all endpoints authenticated, or none. Restivus will allow you to control that on a per-endpoint (not just per-route) level. Role permissions (e.g., user, admin) on endpoints are also available on Restivus, but I don't see anything about that for HTTP.methods.
Meteor Router:
This has been deprecated in favor of Iron Router, please see below.
Iron Router:
Iron Router is awesome, but it is not specifically designed for building REST APIs. Recently they added functions corresponding to the HTTP methods (GET, POST, etc.), but they don't support any form of authentication, and all you have access to is the lower-level Node request and response objects, so you'll be forced to learn how to work with those. Once you do, you'll find that there is some repetitive work to be done in each endpoint, like creating responses with the proper headers and response codes. You'll also have to worry about CORS compliance if your API is being consumed from the browser.
Restivus is actually built on top of Iron Router, and provides a layer of authentication on endpoints. It also abstracts away the need for direct interaction with the Node request and response objects, although they're still there in case we've missed anything. So it's using all the awesomeness of Iron Router with a higher-level API for your coding pleasure. Restivus is great if you're already using Iron Router, since it won't add any additional dependency.
RestStop2:
实际上,我是在一个项目我工作时,它有利于铁路由器被废弃使用RestStop2。 他们有坚实的文档,以及API我比别人高首选。 按照他们的建议,我建立在铁路由器,这是非常受RestStop2启发之上的新包。 Restivus目前正在赞同RestStop2 GitHub的页面上,所以我认为他们一致认为这是一个值得更换。
下面是来自Restivus文档的快速启动部分一点点的代码片段:
if(Meteor.isServer) {
Meteor.startup(function () {
// Global configuration
Restivus.configure({
useAuth: true,
prettyJson: true
});
// Generates: GET, POST on /api/users and GET, DELETE /api/users/:id for
// Meteor.users collection
Restivus.addCollection(Meteor.users, {
excludedEndpoints: ['deleteAll', 'put'],
routeOptions: {
authRequired: true
},
endpoints: {
post: {
authRequired: false
},
delete: {
roleRequired: 'admin'
}
}
});
// Maps to: POST /api/articles/:id
Restivus.addRoute('articles/:id', {authRequired: true}, {
post: {
roleRequired: ['author', 'admin'],
action: function () {
var article = Articles.findOne(this.urlParams.id);
if (article) {
return {status: "success", data: article};
}
return {
statusCode: 400,
body: {status: "fail", message: "Unable to add article"}
};
}
}
});
});
}
现在任何人都碰到这个绊脚石(2013+),检出流星路由器智能包,它提供了方法, 服务器端的路由在创建RESTful接口非常有用。
Meteor.Router.add('/404', [404, "There's nothing here!"]);
为了帮助你在未来的搜索,一定要看看https://atmosphere.meteor.com -一个聪明的包库。 而陨石是版本和包管理非常方便CLI工具。
最优雅的解决方案似乎是HTTP.publish 。 而不是创造别人像一个新的API,它只是增加了HTTP协议现有的流星publish
接口。 这意味着,例如,该Meteor.allow
和Meteor.deny
为HTTP自动工作以及DDP。
例:
如果交到收集和发布功能
HTTP.publish
将安装在下列网址和方法:GET - / API /列表 - 所有公布的数据
POST - / API /列表 - 将文档插入集合
GET - / API /列表/:ID - 找到一个公布的文件
PUT - / API /列表/:ID - 更新文档
DELETE - / API /列表/:ID - 删除文件
myCollection = new Meteor.Collection('list');
// Add access points for `GET`, `POST`, `PUT`, `DELETE`
HTTP.publish(myCollection, function(data) {
// this.userId, this.query, this.params
return myCollection.find({});
});
它并没有完全处理身份验证 。
Yes, you can expose REST endpoints with Meteor using the private API. The functionality will become public soon, but in the meantime, see Can I mount another route handler through ____meteor_bootstrap____.app?.
我知道这是一个老话题,但不是使用任何外部包,您可以使用Web应用程序流星包: https://docs.meteor.com/packages/webapp.html 。
希望能帮助到你!
我以为我会更新的谈话在2014年我还没有找到实现流星REST服务的最佳方式,我希望有人可以点我在另一个方向进行调查。 我测试过3个项目各有各的缺点:
流星路由器我曾与流星路由器,但GitHub的网页说,它只会被修复bug前进,并在所有新项目中使用铁路由器。 我用这个,因为如果它的作品对我来说,是那么的升级是没有必要的,除了一些类型的验证仍在考虑。
铁路由器我有一个简单的例子服务使用铁路由器内置,但它似乎支持REST服务比流星路由器甚至更低,导致服务器崩溃,如果有人帖子无效JSON休息端点。
流星collectionapi公开用于基本的CRUD操作的REST API的支持,但它似乎并不支持比其他的ID查询。