mirrors
/
system-design-primer
mirror of https://github.com/donnemartin/system-design-primer.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Make translation more fluent 

Change "ヒエラルキー" to "階層構造" according to comment
pull/331/head
SATO Yusuke 2020-02-13 02:15:34 +09:00
parent 959ba53516
commit ca5fd9deff
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README-ja.md
View File

@ -1476,7 +1476,7 @@ RESTはデータを公開することに焦点を当てています。RESTでは
#### 欠点: REST
* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。
* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルな階層構造で表せない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。
* 一般的に、RESTでは限られたHTTPメソッドのみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらのメソッドには綺麗にはフィットしません。
* 入れ子になった階層構造を持つ、複雑なリソースを取得する場合、一つのビューを描画するだけでもクライアントとサーバーの間で複数回のやりとりが発生します。例えば、ブログのエントリーの内容と、それに対するコメントを取得する場合が該当します。様々なネットワーク環境で動作するようなモバイルアプリケーションにおいては、このようなやり取りが複数回発生するのは非常に好ましくありません。
* 時が経つにつれて、APIレスポンスにはより多くのフィールドが追加されていきます。この際、古くからあるクライアントは、追加されたフィールドを使いもしないのにすべて受け取ることになります。結果として、ペイロードも膨れますし、レイテンシーも拡大することになります。