From fa199a68b8a02ad8b14bb28f2c402d707e04c1da Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 13 Feb 2020 02:19:47 +0900 Subject: [PATCH] Make translation more fluent MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change "様々なネットワーク環境" to "ネットワークが変化する環境" according to comment --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 3ff0d5da..ce9b447b 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1478,7 +1478,7 @@ RESTはデータを公開することに焦点を当てています。RESTでは * RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルな階層構造で表せない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。 * 一般的に、RESTでは限られたHTTPメソッドのみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらのメソッドには綺麗にはフィットしません。 -* 入れ子になった階層構造を持つ、複雑なリソースを取得する場合、一つのビューを描画するだけでもクライアントとサーバーの間で複数回のやりとりが発生します。例えば、ブログのエントリーの内容と、それに対するコメントを取得する場合が該当します。様々なネットワーク環境で動作するようなモバイルアプリケーションにおいては、このようなやり取りが複数回発生するのは非常に好ましくありません。 +* 入れ子になった階層構造を持つ、複雑なリソースを取得する場合、一つのビューを描画するだけでもクライアントとサーバーの間で複数回のやりとりが発生します。例えば、ブログのエントリーの内容と、それに対するコメントを取得する場合が該当します。ネットワークが変化する環境で動くモバイルアプリケーションにおいては、このようなやり取りが複数回発生するのは非常に好ましくありません。 * 時が経つにつれて、APIレスポンスにはより多くのフィールドが追加されていきます。この際、古くからあるクライアントは、追加されたフィールドを使いもしないのにすべて受け取ることになります。結果として、ペイロードも膨れますし、レイテンシーも拡大することになります。 ### RPCとRESTの比較