劇場のチケットをクライアントに販売するとします。 クライアントは、自分のサービスに独自のアカウントを持つ代理店にしかなれません。 代理店は小さく、叔母が座り込んでバルザーの助けを借りて個人アカウントを処理し、チケットを購入します。 大きなものは、APIを使用して私に接続し、購入できるようにしたいです。
チケットの価格の確認、事前予約、予約の引き換え、購入済みの返品、予約の削除ができます。
質問：APIを整理する最良の方法は何ですか？
Webサービス、および一般的にはRuby on Railsサービスを編成しますが、実装をバイパスできる一般的な原則を述べようとします。 APIの作成準備の過程で読んだ内容を要約し、ソースへのリンクを提供します。
API組織の原則
アーキテクチャ/イデオロギーオプション別： REST 、 SOAP 、 XML-RPCなど。
たくさん読んだ後、RESTを選びました。 メソッドの名前と、このメソッドを呼び出すメソッドなど、必要のない場所では自由度が低くなります。 簡単に言うと、私のチケットはリソースになりました。 チケットを持つ各アクションは、HTTPメソッド+ URLの一意の組み合わせを介して利用できます。 たとえば、事前予約（本質的に、チケット注文の作成）：POST /orders.xml、チケット注文の削除DELETE /orders/1.xml、および価格の表示GET /prices.xml。
HabrとWikipediaで RESTの詳細を読んでください 。
最高のオープンソースRESTおよびRuby on Rails APIの記事は、O'Reillyのご厚意によるRails 3のNutshellの ActiveResourceの章です。 REST APIクライアントとサーバーの両方の観点から状況を説明します。 RESTful APIを使用する必要がある理由を理解するために読むことは非常に役立ちます。 さらに、Ruby On Railsに含まれるActiveResource REST APIクライアントの非常に興味深い実装について説明します。 ActiveResourceは他のいくつかの言語に移植されており、ルビストだけでなく有用です。
ささいなことを差し引いた残りの記事は、上記の記事に投資されます。
実装
実装では、デフォルトでRailsが提供するコンセプトが本当に好きで、 DRYの原則を最大限に活用しました：ユーザー応答（html）を生成するのと同じコントローラーでAPI応答（XML、JSON）を生成します。
ちなみに、DRYを実装するために、XMLテンプレートと新しい Ruby on Rails 3 機能を大幅に節約できる便利なActs_as_apiプラグインがあります。
このトピックには、 このようないくつかの賢明なStackoverflowスレッドがあります。
APIをスタンドアロンモジュールとして実装する
APIを整理するためのDSLがいくつかあります。 たとえば、 Grape、および誰かがGrapeとRuby on Railsを統合する必要がある場合は、ここ： martinciu.com/2011/01/mounting-grape-api-inside-rails-application.html
認証
多くの認証/承認オプションがあります： 基本 、トークンの使用、証明書の使用、 Oauth 。
私がOauthで理解した限りでは、私たちの場合、それは収まりません サーバーにエージェントがログインできるクライアントアカウントがありません。 エンドユーザーはまったくいないため、エンドユーザーについては知りません。そのため、Oauthのオプションは表示されなくなります。
セキュリティに関しては最も信頼できるが、明らかに、クライアントとサーバーの両方で実装するのが最も難しいのは、証明書に基づく認証です。
最も基本的なオプションは基本です（基本的にはユーザー名とパスワード： user ：password@api.myserver.ru/orders.xml）。
ステートレストークンによる認証のオプションを選択しました。これにより、ユーザーはユーザー名とパスワードを使用してブラウザにログインし、注文を作成できると同時に、自動Webサービスを使用して同じユーザー（ただしトークンを使用）で注文を作成できます。 各エージェントには、サーバー上に正確に1人のユーザーが必要です。
はい、もちろん、ログインを開始してから、認証データの漏洩を防ぐためにAPIをHTTPSでラップする必要があることを忘れないでください。 エージェントが自分のアカウントでAPIキーを再生成できるようにする予定です。
さらに、POSTまたはGETパラメーターとして渡されるステートレストークンオプションを選択しました。 Amazonが行ったように、パラメータではなくトークンをHTTPヘッダーに押し込む別のオプションがあります（これはRESTバージョンですが、実装が少し難しくなります）。 しかし、この場合、実装ゲームはろうそくに値するものではないように思えました。 このオプションには特別な利点はありません（多分、リクエスト構造が
少しRESTfulになります）が、手間がかかります。
Webサービスの承認と認証の整理に関するリファレンス：
stackoverflow.com/questions/6134082/restful-web-service-how-to-authenticate-requests-from-other-services
stackoverflow.com/questions/939836/service-based-authentication-using-tokens
実装
Ruby on Rails用の素晴らしいdeviseプラグインがあり、そのためのトークンによる認証用のモジュールがあります 。 文字通り、数行です-これで完了です。
UPD。 同僚からトピックを差し引いた場合、少なくとも意見の相違がある場合は退会します。 そして、トピックの価値の半分は議論にあり、あなたは沈黙しています！