Meteorを使用して安らかなWebサービスを作成するにはどうすればよいでしょうか。同じバックエンドに接続するアプリをAppceleratorで作成したいと思います。
Meteorはこの問題を解決できますか?
私はMeteorpediaでこれについて完全な書き込みをしました:
http://www.meteorpedia.com/read/REST_API
この投稿では、RESTインターフェースを作成するための6つのオプションすべてを、最高レベル(たとえば、すべてを処理するスマートパッケージ)から最低レベル(たとえば、独自のconnectHandlerの作成)までレビューしています。
さらに、RESTインターフェースを使用する場合の投稿は、Meteorで行うのが正しいか間違っているかをカバーし、Meteor RESTテストツールを参照し、CORSセキュリティ問題などの一般的な落とし穴について説明します。
私はもともとここでこの質問に答えましたが、要約すると:
データの上にRESTfulメソッドを追加するには、Meteor用に作成されたCollectionAPIを調べてください。
https://github.com/crazytoad/meteor-collectionapi
データベースにアクセスするための認証については、このプロジェクトをご覧ください。
https://github.com/meteor/meteor/wiki/Getting-started-with-Auth
どちらも開発中は間違いなく幼稚ですが、RESTful APIを作成して、モバイルネイティブクライアントと非常に簡単に統合できます。
これが古いスレッドであることは知っていますが、誰かが遭遇した場合に備えて、Meteor0.9.0以降でRESTAPIを作成するためのパッケージを公開しました。
https://github.com/kahmali/meteor-restivus
これはRestStop2に触発され、IronRouterのサーバー側ルーティングで構築されました。私のそれほど謙虚な意見では、これまでにここに投稿されたものよりも優れた解決策です。
更新:なぜそれが言及されたものよりも「優れた」解決策であると思うのかを明確にするために、それぞれの違いを指摘します。
CollectionAPI:
CollectionAPIは、コレクションに対する非常に基本的なCRUD操作の公開に限定されています。モバイルアプリでRESTAPIを使用している私の使用では、ドキュメント全体を送信するのは非常に無駄になる可能性があり、ほとんどの場合、データの追加処理を行う必要があります(たとえば、Googleクラウドメッセージをフレンドを追加するためのRESTエンドポイント。ただし、フレンドが正常に追加された場合のみ)。CollectionAPIは、エンドポイントが実行される前に実行されるフックを提供しますが、私が理解していることから、応答の直前には何もないため、返されるデータを変更する方法はありません。認証の場合、CollectionAPIを使用すると、各リクエストで渡す必要のあるauthTokenを定義できます。これは、アプリにハードコードされているように見えるため、従来のAPIキーのように機能します。
Restivusは、コレクションの自動化された作業に限定されないため、エンドポイントを完全に制御できます。これで、CollectionAPIに含まれるすべての機能が提供されます。ユーザー認証と役割のアクセス許可もサポートしているため、要求を行っているユーザーを識別できます(そして、認証されたエンドポイント内からそのユーザーに簡単にアクセスできます)。それを支援するために、ログインとログアウトのエンドポイントも提供します。最後にRestivusのコード例を示します。
HTTP.publish:
私が理解していることから、これは、コレクションに対する基本的なCRUD操作の公開に限定されているという点でCollectionAPIに似ています。これは、より具体的にMeteorの公開に関連付けられており、公開機能を使用してGETリクエストを処理できます。ドキュメントに混乱していますが、基本認証が利用できる場合とできない場合があります。私はこれまでこれを使用したことがありませんが、APIの大ファンではないため、少し不格好に感じます。より広範囲に公開したら、それを再検討しようと思います。同じチームには、公開機能へのアクセスを提供しないHTTP.methodsと呼ばれる別のパッケージがありますが、Restivusと同様のAPIを備えており、当時は同様の機能を備えています。
Restivusは、公開機能の使用に制限されないため「優れた」ものであり、したがって、エンドポイントをよりきめ細かく制御できます。公開関数を外部APIに公開することだけを検討している場合は、HTTP.publishを使用することをお勧めします。RestivusはよりシンプルなAPIも備えており、HTTP PATCHメソッドをサポートしています(他のパッケージはこれを認識していないようです)。彼らのHTTP.methodsパッケージは、PATCHサポートがないことを除けば、Restivusと非常によく似ています。基本認証は提供されますが、すべてのエンドポイントを認証できるか、まったく認証できないと思います。Restivusを使用すると、エンドポイントごと(ルートごとだけでなく)レベルでそれを制御できます。エンドポイントでのロール権限(ユーザー、管理者など)はRestivusでも利用できますが、HTTPについては何もわかりません。
Meteorルーター:
これはIronルーターを優先して廃止されました。以下を参照してください。
Iron Router:
Iron Routerは素晴らしいですが、RESTAPIを構築するために特別に設計されたものではありません。最近、HTTPメソッド(GET、POSTなど)に対応する関数が追加されましたが、これらはどの形式の認証もサポートしておらず、アクセスできるのは下位レベルのノード要求オブジェクトと応答オブジェクトだけなので、それらを扱う方法を学ぶことを余儀なくされます。これを行うと、適切なヘッダーと応答コードを使用して応答を作成するなど、各エンドポイントで実行する必要のある反復作業がいくつかあることがわかります。APIがブラウザから消費されている場合は、CORSコンプライアンスについても心配する必要があります。
Restivusは実際にはIronRouterの上に構築されており、エンドポイントで認証のレイヤーを提供します。また、Nodeのリクエストオブジェクトとレスポンスオブジェクトとの直接のやり取りの必要性を抽象化しますが、何かを見逃した場合に備えて、それらはまだ存在しています。つまり、コーディングを楽しむために、IronRouterのすべての素晴らしさを高レベルのAPIとともに使用しています。Restivusは、依存関係を追加しないため、すでにIronRouterを使用している場合に最適です。
RestStop2:
Iron Routerが廃止されたときに、作業中のプロジェクトでRestStop2を実際に使用していました。彼らはしっかりしたドキュメントを持っていて、私が他のものよりも好んだAPIを持っていました。彼らの提案に従って、私はIron Routerの上に新しいパッケージを作成しました。これは、RestStop2に非常に触発されています。Restivusは現在RestStop2GitHubページで承認されているので、彼らはそれが価値のある代替品であることに同意していると思います。
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インターフェイスの作成に役立つサーバー側ルーティングのメソッドを提供するMeteorRouterスマートパッケージをチェックしてください。
Meteor.Router.add('/404', [404, "There's nothing here!"]);
今後の検索を支援するために、https://atmosphere.meteor.com(スマートパッケージリポジトリ)を必ず確認してください。また、Meteoriteは、バージョンとパッケージを管理するための非常に便利なCLIツールです。
最も洗練されたソリューションはHTTP.publishのようです。他のAPIのように新しいAPIを発明するのではなく、既存のMeteorpublish
インターフェースにHTTPプロトコルを追加するだけです。これは、たとえば、HTTPとDDPで自動的に機能するMeteor.allow
ことを意味します。Meteor.deny
例:
コレクションと公開関数を渡された場合、
HTTP.publish
は次のURLとメソッドにマウントされます。GET-/ api/list-すべての公開データ
POST-/api/list-コレクションにドキュメントを挿入
GET-/api/ list /:id-1つの公開ドキュメントを検索
PUT-/ api / list /:id-ドキュメントを更新
DELETE -/ api / list /: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({});
});
まだ完全には認証を処理していません。
Meteorを使用してRESTfulサービスを作成できると思いますが、それは実際にはフレームワークの目的ではありません。Meteorの主な利点の1つは、クライアントとサーバー間の緊密な相互作用であり、Webサービスにはクライアント側。node.jsで独自にWebサービスバックエンドを作成するか、Rubyが好きな場合はhttps://github.com/intridea/grapeのようなものを作成することを検討することをお勧めします。
はい、プライベートAPIを使用してMeteorでRESTエンドポイントを公開できます。この機能はまもなく公開されますが、それまでの間、____ meteor_bootstrap____。appを介して別のルートハンドラーをマウントできますか?を参照してください。。
これは古いトピックですが、外部パッケージを使用する代わりに、Meteor WebAppパッケージを使用できます: https ://docs.meteor.com/packages/webapp.html 。
それが役に立てば幸い!
2014年の会話を更新しようと思っていました。MeteorでRESTサービスを実装するための完璧な方法をまだ見つけていません。誰かが私を別の方向に向けて調査してくれることを、望んでいます。私は3つのプロジェクトをテストしましたが、それぞれに欠点があります。
meteor-router 私はmeteor-routerを使用しましたが、githubページには、今後のバグの修正と、すべての新しいプロジェクトでのIronRouterの使用のみが記載されています。そのまま使用できる場合は、ある種の認証を除いてアップグレードは必要ないため、これを使用することを検討しています。
iron-router Iron Routerを使用して構築された簡単なサンプルサービスがありますが、meteor-routerよりも少ないRESTサービスをサポートしているようで、誰かが無効なjsonをrestエンドポイントに投稿するとサーバーがクラッシュします。
meteor-collectionapi 基本的なCRUD操作のRESTAPIを公開しますが、ID以外のクエリをサポートしているようには見えません。