11

Netflix API の .NET ラッパー API を作成しています。

この時点で、URL を文字列または URI オブジェクトとして表すことを選択できます。私にはどちらにも良いケースがあるようです。

では、API を使用しているとしたら、どちらを優先しますか?

4

3 に答える 3

17

以下の引用は以下からのものです: Framework Design Guildelines .Net でフレームワークを開発しているすべての人に、この本
を強くお勧めします。

System.Uri を使用して URI / URL データを表してください。
(パラメータ、プロパティ、および戻り値の場合)

System.Uri は、URI を表すより安全でリッチな方法です。プレーン文字列を使用した URI 関連データの広範な操作は、多くのセキュリティと正確性の問題を引き起こすことが示されています。

System.Uri パラメーターを使用して、最も一般的に使用されるメンバーに文字列ベースのオーバーロードを提供することを検討してください。

ユーザーから文字列を取得する使用パターンが十分に一般的な場合は、文字列を受け入れる便利なオーバーロードを追加することを検討する必要があります。文字列ベースのオーバーロードは、Uri ベースのオーバーロードに関して実装する必要があります。

文字列を受け入れるバージョンですべての Uri ベースのメンバーを自動的にオーバーロードしないでください。

一般に、Uri ベースの API が推奨されます。文字列ベースのオーバーロードは、最も一般的なシナリオのヘルパーとなることを意図しています。したがって、Uri ベースのメンバーのすべてのバリアントに対して、文字列ベースのオーバーロードを自動的に提供しないでください。選択して、最も一般的に使用されるバリアントに対してのみそのようなヘルパーを提供してください。

編集 (コメントごと):この本は具体的に次のように述べています。System.Uri / UriBuilder を使用するために必要な追加の理由がわかりません。さらに、フレームワークを利用して URI を読み取り/操作したくないのはなぜですか?

他の人が使用する API を設計するときは、それらを親しみやすく、信頼できるものにすることが重要です。このため、この本では言及されていますが、一般的な機能には「適切な」オーバーロードを提供する必要があります。ただし、正確性を確保するために、常に URI を使用して基になるコードを実装する必要があります。

あなたの要望、または文字列のみを使用する理由を明確にしていただけますか?

于 2008-10-18T08:36:19.310 に答える
1

URIとして表現する必要があると思います。ただし、私があなたの API のユーザーであり、API を使用するために文字列ベースの URL を URI に継続的に変換しなければならない場合、私は腹を立てているユーザーになります。

私が言いたいのは、あなたの API を消費するオーディエンスの種類を評価する必要があるということです。

于 2008-10-18T09:05:41.140 に答える
0

私が見つけた 1 つのことは、string-accepting メソッドを作成している間、ユーザーが不正な文字列を渡した場合にメソッドから伝播するUriように、文字列を検証するためだけにとにかくオブジェクトを初期化する必要があるということでした。しかし、FxCop から (当然のことながら) 怒鳴られた後に行ったように、s のみUriFormatExceptionを受け入れる場合は、入力が有効であることを常に認識できます。これは、API を正しく設計していることを示す非常に良い兆候のように思えます。Uri

于 2008-10-18T09:13:21.000 に答える