問題タブ [url-design]

翻訳された Web サイトの URL の最適な戦略は何ですか? 私がよく目にするのは、次のようなものです。

これには、ユーザーが URL を変更することによって別の言語に手動で切り替えることができるという (マイナーな) 利点があります。不利な点は、URL がデフォルト言語ではないすべてのページの間違った言語のスラッグで構成されていることです。それはSEOのペナルティを引き起こすと思います。

別の方法として、スラッグも翻訳し、オプションで言語識別子も省略します。

ロシア語、中国語、アラブ語など、一部の言語は実際には「緩慢」になるのに適していません。ほとんど意味のない音訳になってしまいます。

ユーザーのパスワードをリセットする機能を提供したいと考えています。この呼び出しは明らかに認証を必要としません。まず、次のようなことを考えました。

DELETE /users/{id}/password: 電子メールでユーザーに送信されるリセット トークンを生成します。

POST /users/{id}/password: 本文に新しいパスワードと有効なリセット トークンが必要です

しかし問題は、アプリケーションまたは Web サイトがユーザーの ID を提供できないことです。ユーザーに要求できるのはメール アドレスだけだからです。

API への他の (認証されていない) 呼び出しが多数ありますが、ID は存在せず、ユーザーは電子メールによってのみ識別されます。

私たちのチームでは、次のソリューションについて話し合いました。

• URL の ID をユーザーの電子メールに置き換える
• URL から ID を切り取り、メールにクエリ パラメータを指定します。

これら 2 つのどちらかを選択する必要がある場合は、最初の 1 つを選択します。なぜなら、クエリ パラメーターで必須のものを提供することは RESTful ではないと思うからです。これらは常に、リソースのフィルター処理など、オプションの何かを表しているからです。これらの URL を設計するためのより良い方法はありますか、または ID をユーザーの電子メールに置き換えて、REST 制約に関して問題なく使用できますか?

エンティティとサブエンティティの 2 つのモデルがあります。エンティティは、接続された多数のサブエンティティを持つことができます (1 対多の関係)。

サーバーには、新しい Subentity を返すメソッドがあります ( GetEmptySubentity と呼びましょう)。ポイントは、新しいサブエンティティを作成するときにボタンを押すと、モデルがサーバーから取得され、いくつかのフィールドが事前に入力されていることです。これらの Subentity の事前入力値の一部は対応するエンティティに依存するため、このリクエストでエンティティ ID を渡す必要があります。

空の Subentity を取得するための正しい URL は/Entity/{id}/Subentity/emptyのようにする必要がありますか? それとも私は何か間違っていますか？

次のように、わかりやすい URL を使用しています。

フレンドリー URL では、写真の ID を追加する必要がありますが、周りを見回すと、ID をフレンドリー URL に追加する方法が 2 つあります。

また

片道を使うメリットはありますか？それとも好みや個人的な好みの問題ですか？

私の知る限り、すべてのリソースには REST 設計の URL があります。たとえば/user/28、ID が 28 のユーザーの URL は、/usersすべてのユーザーを返します。

リソースの出力形式を表す方法がいくつかあります。

• のようなクエリパラメータを渡すformat
• 拡張機能を使用して指定します（ユーザーをjson形式で取得するには、/usersurlをに変更します）/users.json
• Accepthttp ヘッダーを設定して、要求された形式 (xml、json、xls、...) を指定します。

私はウェブを検索しましたが、正しい方法はAcceptヘッダーを設定しているようです。しかし、ユーザーのリストを xls 形式でダウンロードするための http リンク (href で指定) が必要な場合は、できません! また、ブラウザーで xls をダウンロードする場合、多くの問題が発生します (ajax を使用する必要があります)。そのため、xls は ajax などを使用してダウンロードする必要があります)。

それが最善の方法である場合、ダウンロード リンクの解決策は何ですか。そうでない場合、どの解決策が優れていますか?

私は Web アプリケーションを構築していますが、1 つの質問に出くわしました。ここオフィスでは意見が分かれているので、質問を共有して、最高の（あなた！）に耳を傾けるといいと思いました。

アプリケーションの URL を作成するときは、標準の形式を使用することを考えていました。

Clients モジュールのインデックスは次のようになります。

次に、クライアントの詳細ページの場合は次のようになります。

最後に、クライアントの更新ページの場合は次のようになります。

ここに質問があります：

更新ページの URL のパラメーターの順序を変更するのはどうですか? 次のようになります。

([client_slug]パラメーターは常に URL の末尾に保持します。)

URLは常に「ドメイン/モジュール/関数/オブジェクト」の形式に従うため、私にとってはより理にかなっていますが、ここにいる一部の人にとってはそうではありません。

どう思いますか？SEOへの影響はありますか、それとも個人的な選択ですか?