0

REST API を作成するリクエストを受け取りました。クライアントから提供された例で少し混乱しました。以下に示すように、@. URI の残りの部分は、予想どおりです。

これは有効ですか？これは、これまでに見たことのない奇妙な cURL 形式である可能性があると思いました。

https://{application_id}:{api_secret}@api.example.com/entity/{entity_id}/ 
https://{application_id}:{api_secret}@api.example.com/entity/{entity_id}/entity_locations/{locations_id}/

誰かがこのフォーマットを以前に見たことがあるかどうかを確認していますか?

4

1 に答える 1

1

URIはさまざまな部分で構成されており、そのうちの1つは権限部分であり、オプションのusername:password要素を特徴とすることができます。

完全なスキームは次のとおりです。

scheme://username:password@domain:port/path?query_string#fragment_id

このようにして、REST APIはステートレスのままになります[セッションにデータを保存するなど、以前のアプリの状態に依存しません]。ただし、ルートを明示的に使用するのではなく、基本HTTP認証username:password@stuffに依存することをお勧めします。これにより、クレデンシャルは少なくともBase64でエンコードされて送信されます。

編集：今あなたが尋ねているBasicAuthについての簡単なメモ-物事はこのようになります：

  • あなたはにリクエストをしhttp://johndoe:12345@service/api/foo/barます;
  • クレデンシャルは良いですか？わかりました、あなた200 OKは適切な体で反応を得ます。
  • 彼らではないですか？401 Unauthorized応答があります。

後者の場合、ログインポップアップでユーザーにプロンプ​​トを表示するのはブラウザ[またはリクエストを実行する他のプログラム/スクリプト]です。

通常、ブラウザは、毎回要求しないようにクレデンシャルをキャッシュするように要求しますが、これは、クレデンシャルが送信されないことを意味するわけではありません。保護されたリソースへのすべての要求がそのようなヘッダーで示されるだけです。

Authorization Basic base64encode(username:password)

base64encode文字列をエンコードするカスタムの方法はどこにありますかusername:password。

于 2012-08-26T15:59:09.103 に答える