0

スレッド内のコメントを取得および保存するための RESTful API を構築しています。

コメント スレッドは、任意の URI によって識別されます。通常、これは、コメント スレッドが関連する Web ページの URL です。この設計は、Disqus がシステムで使用しているものと非常によく似ています。

このように、すべての Web ページで、関連するコメント スレッドを照会するためにクライアントに追加のデータを保存する必要はありません。必要なのは、問題のページへの正規の URL だけです。

私の現在の実装では、次のように URI を文字列としてエンコードすることで、URI をリソースとして機能させようとしています。

/comments/https%3A%2F%2Fexample.org%2Ffoo%2F2345%3Ffoo%3Dbar%26baz%3Dxyz

ただし、アプリケーションにディスパッチする前に、リクエスト URI は常にサーバーによってデコードされ、

/comments/https://example.org/foo/2345?foo=bar&baz=xyz

デコードされたリソース名にパス区切り文字とクエリ文字列が含まれているため、API でのルーティングが混乱するため、これは機能しません (私のルーティング構成では、リクエスト パスに/comments/文字列が続くと想定しています)。

それらを二重にエンコードするか、URI エンコード以外のエンコード方式を使用することもできますが、そうするとクライアントが複雑になるため、これを回避しようとしています。

具体的な質問が 2 つあります。

  1. 私の URI 設計は、私が引き続き取り組むべきものですか、それとも私がやろうとしていることを実行するためのより良い (ベスト?) プラクティスはありますか?

  2. Martini の「マイクロフレームワーク」を使用して実装された Go プロセスで API リクエストを処理しています。URI でエンコードされたリソース名をエンコードしたままにするために、Go または Martini 固有のことを行う必要がありますか? おそらく、リソース名が単なる文字列ではなく、URL エンコードされた文字列であることをルーティング サブシステムに示唆する方法でしょうか?

4

1 に答える 1

0

あなたのアプリケーションの URL スキームについてはわかりませんが、% でエンコードされた単一の値は、それらが表す文字の代わりに URL で有効であり、サーバーによってデコードされる必要があります。URL 予約文字を値として渡し、それらを URL の一部としてデコードしないようにする必要がある場合は、ダブル % エンコードする必要があります。これはかなり一般的な方法であり、クライアントとサーバーに追加される複雑さはそれほど大きくなく、短いコメントで十分です。

つまり、URL 文字を渡す必要がある場合は、ダブル % エンコードすれば問題ありません。

于 2014-04-20T15:56:15.463 に答える