2

だから私は、CMS に新しい、光沢のある REST Web サービスを追加しようとしています。REST の「ルール」に厳密に従う必要があるため、GET/POST/PUT/DELETE と適切な論理 URL を使用する必要があります。私のデザインは、Apigee のベスト プラクティスに大きく影響を受けています。

CMS はカテゴリのツリーを管理します。各カテゴリには多数の記事を含めることができます。多言語プロジェクトの場合、カテゴリは言語ごとに複製されます (そのため、記事はその ID と言語 ID によって一意に識別されます)。構造はすべての言語で同じで、位置のみが異なります (したがって、すべての言語でカテゴリ X にカテゴリ Y と Z が含まれますが、言語 1 では Y が Z の前にあり、言語 2 ではその逆になる可能性があります) 。新しい記事またはカテゴリを作成すると、常にすべての言語でコピーが作成されます。削除も同じように機能するため、記事は常にすべての言語で削除されます。

参考までに: 言語は、数値 ID またはロケール ( などen_US) によって識別されます。

(すべての URI の前に先頭をイメージしてください/v1。この質問には何も追加されないため、スキップしました。)`

私の現在のアプローチは、次のような URL スキームを使用しています。

GET    /articles               :(  returns all articles in all languages
GET    /articles/:id-:langid   :)  returns a single article in a given language
POST   /articles               :)  creates a new article
PUT    /articles/:id-:langid   :)  update a single article in a given language
DELETE /articles/:id           :)  delete an article in all languages

しかし...

言語を識別する方法は？

現在、各言語に割り当てられているロケールは一意である必要はないため、まれに 2 つの言語が同じロケールを持つことがあります。ID を使用すると、一意であることが保証されます。

URL が読みやすくなるため、ロケール (ほとんどの場合、強制的に小文字にする) を使用すると便利です。しかし、これは

  • ロケールが重複するプロジェクトにつながる可能性があります。
  • クライアントは最初にロケールを取得する必要があります (ただし、クライアントはとにかく言語 ID を取得する必要があると思いますので、それで問題ありません)。

これに対する正確な解決策を1つにして、ロケールを使用する傾向があります。しかし、重複するロケールを危険にさらす価値はありますか?

langid=X（以下で交換可能な画像を作成できlocale=xx_xxます。）

言語は階層要素であるべきか?

ほとんどの場合、API のクライアントは、すべてではなく特定の言語の記事を取得する必要があります。GET パラメータと offer を許可することで、これを解決できましたGET /articles?langid=42。しかし、非常に一般的なユースケースであるため、オプションのパラメーターを避けて明示的にしたいと思います。

これは につながりますがGET /articles/:langid、これにより、言語は API 内の階層レベルであるという概念が導入されます。やるなら他の動詞も統一したい。新しい URL レイアウトは次のようになります。

GET    /articles/:langid       :)  returns all articles in a given language
GET    /articles/:langid/:id   :)  returns a single article in a given language
POST   /articles               :(  creates a new article in all languages
PUT    /articles/:langid/:id   :)  update a single article in a given language
DELETE /articles/:langid/:id   :(  delete an article in all languages

また

GET    /:langid/articles       :)  returns all articles in a given language
GET    /:langid/articles/:id   :)  returns a single article in a given language
POST   /articles               :(  creates a new article in all languages
PUT    /:langid/articles/:id   :)  update a single article in a given language
DELETE /:langid/articles/:id   :(  delete an article in all languages

これはにつながります...

グローバルアクションをどうするか?

上記のレイアウトには問題がPOSTありDELETE、すべての言語で機能しますが、URL は 1 つの言語でしか機能しないことを示唆しています。したがって、レイアウトを変更できます。

GET    /articles/:langid       :)  returns all articles in a given language
GET    /articles/:langid/:id   :)  returns a single article in a given language
POST   /articles               :)  creates a new article in all languages
PUT    /articles/:langid/:id   :)  update a single article in a given language
DELETE /articles/:id           :)  delete an article in all languages

これは、言語レベルが時々しか存在せず、システムの内部について多くのことを知る必要があるため、やや混乱したレイアウトになります。明るい面では、これはシステムと非常によく一致し、内部の仕組みと非常によく似ています.

犠牲？

では、どこで犠牲を払うのですか？見栄えの良い URL レイアウトを実現するためにエイリアス URL を導入する必要がありますが、バックグラウンドで意図しないことを行う必要がありますか?

4

2 に答える 2

0

/en_us/articles私の最初のアプローチは、URL のオプションのプレフィックスとして language を使用/en_us/articles/:idすることでしたAccept-language。RFC 2616で定義されています。Microsoft の WebAPI は、フォーマット ネゴシエーションにこのアプローチを使用しています。

于 2012-11-02T21:45:57.477 に答える