1

私は REST を使い始めたばかりで、この設計モデルに従って最初のアプリの構築を開始しました。私が収集できるアイデアから、あなたのウェブサイト自体が消費者である API のようなサービスを構築することです。

私のWebアプリは多くのAJAX呼び出しを行うので、これは理にかなっていますが、セッションの使用を避けるために各リクエストを認証するのは少し無駄に思えます. これは、REST 設計プロセスの一部として受け入れなければならないものですか?

また、ajax 呼び出しを行うことは正常に機能しますが、たとえば、ユーザー プロファイルのビューを表示するだけでよいということは、このデータを取得するために API に対して curl 呼び出しを行う必要があることを意味しますか? この時点で、私は内部で作業していることを知っているので、認証は必要ですか?

4

3 に答える 3

1

いくつかのコメント:

アプリケーション全体を RESTインターフェースを持つように設定することもできますが、内部的に呼び出すことができるように設定する必要があります。HTTP から呼び出し、HTTP で結果を取得するのは、入力処理と出力レンダリングだけです。したがって、これらの懸念を分離すると、次のフローが得られますinput-processing -> method call -> data return -> data rendering。最初と最後のビットを剃って、何が残った？コードで使用できるデータを返す関数呼び出し。「外部」関数呼び出しを「内部」関数呼び出しに変換し、「内部」データを「外部」(xml、json、html、必要なものは何でも) にレンダリングする機能を分離することで、アプリを効率的にしながら、完全に REST 対応にすることができます。

外部呼び出しを許可する場合は認証が必要です。他のユーザーに特定の方法でデータを取得できることを「伝え」なくても、データは簡単に発見できます。この認証にセッションを使用したくない理由がわかりません（これは、前述の「外部」呼び出しから内部呼び出しへの変換で発生する可能性が最も高いです。「セッションを使用しない」ことは要件にしませんが、複数の認証方法 (セッション、リクエストごとの再認証、トークンなど) を許可できない理由にはなりません。

于 2012-06-25T23:34:55.320 に答える
0

通常、私は標準の PHP を使用して呼び出すことができるインターフェイスを作成し、認証と RESTful アクセスを追加するインターフェイスをこれに追加することを好みます。たとえば、次のようにアクセスできます。

http://example/api/fetchAllFromUsers?auth-key=XXXXX

つまり、次のようになります。

$internalInterface = new Api();
$internalInterface->fetchAllFromUsers();
于 2012-06-25T23:33:37.117 に答える
0

毎回認証する代わりに、セッションを識別する状態のチャンクを (Cookie などに) 保存し、それを使用します。次に、(構文を使用して) GET のパラメーターになるか、?name-valueURI 自体の一部にすることができます。

 http://example.com/application/account/ACCTNO/TOKEN

whereACCTNOとTOKENはそれぞれアカウントと認証セッションを識別します。

これは最初は少し不安定に思えるかもしれませんが、アプリケーションが大きくなっても、セッション状態などによる複雑な負荷分散を必要とせず、単純なプロキシ スキームで問題なく動作することを意味します。これにより、アーキテクチャの複雑さが驚くほど軽減されます。

于 2012-06-25T23:35:29.023 に答える