私はソーシャルネットワーキングサイトを開発し、アプリケーションのコアを完全にRESTしたいと考えています。ユーザーはパスワードでログインします。さて、私の質問は、すべての要求がパスワードの最後にwww.site.com/index.php?p=pass&l=loginのようなパスワードとログインのペアを必要とするのですか？私は、すべての要求でそれを求めることについて少し神経質になります。私は何かが欠けていることを知っています...誰もがパケットに詮索してパスワードを取得して簡単にログインすることができないので、それはそうではありません。私はHTTPSで行われたすべてのリクエストが意味をなさないと思っています（私はそれがリソースに課税されていると読んでいます）。リクエストごとにREST APIにパスワードとログインが必要ですか？
私が理解する必要がある欠けている部分を記入してください。
まず、SSLを使用することが高すぎることが分かっていない場合は、SSLを使用してください。パフォーマンスの最適化の前にセキュリティが提供されます。
ユーザー名とパスワードの受け渡しについて：通常、「APIアクセストークン」などがあります。実際にはユーザー名/パスワードではありませんが、誰かがそれを持っている場合、APIリクエストを行うことができます。これらは、あなたが好きなように、限定的または無限の有効性を持つことができます。トークンを署名にすることさえできます - ユーザーは何らかのキーで要求に署名し、署名を検証します。
はい、各API要求は最後から独立しているため、HTTP基本認証または同等のものを使用するか、APIトークン（または他の署名デバイス）をすべての要求に渡す必要があります。
+1をお読みください。これらの保存されたサイクルは、あなたが災害復旧で一週間を過ごすときには何の価値もありません！ – jprofitt
従来のセッショントラッキングルールは、他のシステムと同様にRESTに適用されます。あなたの最善の策は、ログインを最前面にしてから、クライアントにすべてのリクエスト（クエリ文字列、クッキー、またはあなたのもの）に渡すトークンをクライアントに返すことです。トークンは、すべての適切なセッション情報、特にユーザーのIDなどを含むサーバーサイトのデータストアにインデックスを付けます。
通常、すべてで再利用できるトークンを生成するログインメソッドを呼び出します次のリクエスト
私の助言は、すべての要求に対してSSLを強制的に使用することです。もしそうでなければ、安全なログインを要求し、その特定のセッションの一時的なトークンを（セッションIDと同様に）生成する必要があります。
Flickr APIでOAuthがどのように使用されているのかを確認するには、以下の図を参照してください。このシナリオでは、一時トークンを使用して永久トークンとトークンシークレットを要求します。撮影
：http://www.flickr.com/services/api/auth.oauth.html#access_token
*要求署名*のOauthおよび/または他のトークンベースの認証メカニズムを調査。私は完全な答えとしてこれを書く時間がありませんが、これはあなたに何か検索する必要があります。 – deceze
ありがとう - 確かにそれらの詳細については、パフォーマンスの前にセキュリティのために – netrox