From ed3d9d965d68d5d40b0e10bd6fc68a246e65be45 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:18:37 +0900 Subject: [PATCH 01/42] Correct mistranslations - Make translation more fluent. - "requests and responses", and "servers" were missing in the translation. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 0fcee96c..1096cd25 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1328,7 +1328,7 @@ def set_user(user_id, values): ### Hypertext transfer protocol (HTTP) -HTTP はクライアントとサーバー間でのデータをエンコードして転送するための手法です。リクエスト・レスポンスに関わるプロトコルです。クライアントがリクエストをサーバーに投げ、サーバーがリクエストに関係するコンテンツと完了ステータス情報をレスポンスとして返します。HTTPは自己完結するので、間にロードバランサー、キャッシュ、エンクリプション、圧縮などのどんな中間ルーターが入っても動くようにできています。 +HTTPはリクエスト・レスポンス型のプロトコルです。クライアントがリクエストを投げると、サーバーはそのリクエストに対応するコンテンツと完了ステータスの情報をレスポンスとして返します。HTTPは自己完結したプロトコルです。リクエストやレスポンスが数多くのサーバーやルーターを通過し、その間にロードバランシング、キャッシュ、暗号化、圧縮などが行われていても、問題なく動くようにできています。 基本的なHTTPリクエストはHTTP動詞(メソッド)とリソース(エンドポイント)で成り立っています。以下がよくあるHTTP動詞です。: From fabd2eff87cc0764366ebdbe0abd2a540e8060ca Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:19:54 +0900 Subject: [PATCH 02/42] Correct mistranslations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "下位" is more commonly used for the translation of "lower-level" rather than "低級" (lower-class). - "依存" (rely/addiction) is misleading word in this context, and "～の上で" ("based on") is more suitable. - "アプリケーション層" is more commonly used for the translation of "application layer". --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 1096cd25..6cb3b57a 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1342,7 +1342,7 @@ HTTPはリクエスト・レスポンス型のプロトコルです。クライ *何度呼んでも同じ結果が返ってくること* -HTTPは**TCP** や **UDP** などの低級プロトコルに依存しているアプリケーションレイヤーのプロトコルである。 +HTTPはアプリケーション層のプロトコルで、**TCP** や **UDP** など下位のプロトコルの上で動作します。 #### その他の参考資料、ページ: HTTP From 90f74d85e51188cda180a7c9bc6658d58ba898c1 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:23:01 +0900 Subject: [PATCH 03/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "oriented" was missing in the translation. - "～の上で動作する" is more suitable for the translation of "over" rather than "～の上で成り立つ" ("carry on"). - Uniform the translation of "Connection" to "コネクション". - "確立" is more commonly used for the translation of "establish" rather than "開始" ("start"). - "切断" is more commonly used for the translation of "terminate" rather than "解除" ("cancel"). - The word "handshake" is not translated. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 6cb3b57a..65ced739 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1358,7 +1358,7 @@ HTTPはアプリケーション層のプロトコルで、**TCP** や **UDP** Source: How to make a multiplayer game

-TCPは[IP network](https://en.wikipedia.org/wiki/Internet_Protocol)の上で成り立つ接続プロトコルです。接続は[handshake](https://en.wikipedia.org/wiki/Handshaking)によって開始、解除されます。全ての送信されたパケットは欠損なしで送信先に送信された順番で到達するように以下の方法で保証されています: +TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol)の上で動作する、コネクション指向のプロトコルです。コネクションの確立と切断は[ハンドシェイク](https://en.wikipedia.org/wiki/Handshaking)によって行われます。送出されたパケットはすべて、元々の順序通りに、かつデータ破損なしに宛先へ到達することが、以下の方法で保証されています: * シーケンス番号と[checksum fields](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation)が全てのパケットに用意されている * [Acknowledgement](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks))パケットと自動再送信 From 953d85c72cf99869c283300b20efc2e4a20b33dd Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:24:58 +0900 Subject: [PATCH 04/42] Correct mistranslation - Make the translation more fluent. - "checksum fields" is not translated. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 65ced739..19efd38b 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1360,7 +1360,7 @@ HTTPはアプリケーション層のプロトコルで、**TCP** や **UDP** TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol)の上で動作する、コネクション指向のプロトコルです。コネクションの確立と切断は[ハンドシェイク](https://en.wikipedia.org/wiki/Handshaking)によって行われます。送出されたパケットはすべて、元々の順序通りに、かつデータ破損なしに宛先へ到達することが、以下の方法で保証されています: -* シーケンス番号と[checksum fields](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation)が全てのパケットに用意されている +* 各パケットにあるシーケンス番号と[チェックサム](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation) * [Acknowledgement](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks))パケットと自動再送信 もし送信者が正しいレスポンスを受け取らなかったとき、パケットを再送信します。複数のタイムアウトがあったとき、接続は解除されます。TCP は[フロー制御](https://en.wikipedia.org/wiki/Flow_control_(data)) と [輻輳制御](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control)も実装しています。これらの機能によって速度は低下し、一般的にUDPよりも非効率な転送手段になっています。 From 169160eb4b35eee86b59cb2fcede114e0ebdb159 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:26:47 +0900 Subject: [PATCH 05/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Make the translation more fluent. - Uniform the translation of "Connection" to "コネクション". --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 19efd38b..47b69034 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1363,7 +1363,7 @@ TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol) * 各パケットにあるシーケンス番号と[チェックサム](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation) * [Acknowledgement](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks))パケットと自動再送信 -もし送信者が正しいレスポンスを受け取らなかったとき、パケットを再送信します。複数のタイムアウトがあったとき、接続は解除されます。TCP は[フロー制御](https://en.wikipedia.org/wiki/Flow_control_(data)) と [輻輳制御](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control)も実装しています。これらの機能によって速度は低下し、一般的にUDPよりも非効率な転送手段になっています。 +送信側に正しいレスポンスが返ってこなかったら、パケットを再送信します。タイムアウトが何度も発生したときは、コネクションをdropします。TCP は[フロー制御](https://en.wikipedia.org/wiki/Flow_control_(data)) と [輻輳制御](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control)も実装しています。これらの保証のために遅延が発生するので、一般的に転送効率はUDPより劣ります。 ハイスループットを実現するために、ウェブサーバーはかなり大きな数のTCP接続を開いておくことがあり、そのことでメモリー使用が圧迫されます。ウェブサーバスレッドと例えば[memcached](#memcached) サーバーの間で多数のコネクションを保っておくことは高くつくかもしれません。可能なところではUDPに切り替えるだけでなく[コネクションプーリング](https://en.wikipedia.org/wiki/Connection_pool)なども役立つかもしれません。 From cfa9322f5baa5d9c0712e1496f5cade1240920c0 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:29:53 +0900 Subject: [PATCH 06/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Uniform the translation of "Connection" to "コネクション". - "確保" is more suitable for the translation of "ensure" rather than "実現" ("realize"). - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 47b69034..f733d6b7 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1365,7 +1365,7 @@ TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol) 送信側に正しいレスポンスが返ってこなかったら、パケットを再送信します。タイムアウトが何度も発生したときは、コネクションをdropします。TCP は[フロー制御](https://en.wikipedia.org/wiki/Flow_control_(data)) と [輻輳制御](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control)も実装しています。これらの保証のために遅延が発生するので、一般的に転送効率はUDPより劣ります。 -ハイスループットを実現するために、ウェブサーバーはかなり大きな数のTCP接続を開いておくことがあり、そのことでメモリー使用が圧迫されます。ウェブサーバスレッドと例えば[memcached](#memcached) サーバーの間で多数のコネクションを保っておくことは高くつくかもしれません。可能なところではUDPに切り替えるだけでなく[コネクションプーリング](https://en.wikipedia.org/wiki/Connection_pool)なども役立つかもしれません。 +高スループットを確保するため、ウェブサーバーでは多数のTCPコネクションを開いたままにしておくことがあります。この場合は、メモリーの使用率が高くなります。ウェブサーバのスレッドと、例えば [memcached](#memcached) サーバーの間で多数のコネクションを張ったままにするのは高くつくかもしれません。この場合、可能であればUDPに切り替える、コネクションプーリング[コネクションプーリング](https://en.wikipedia.org/wiki/Connection_pool)を使うといった方法が役立つかもしれません。 TCPは高い依存性を要し、時間制約が厳しくないものに適しているでしょう。ウェブサーバー、データベース情報、SMTP、FTPやSSHなどの例に適用されます。 From efe3878210c1d69e92ee498d501fef5565222f28 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:30:26 +0900 Subject: [PATCH 07/42] Correct mistranslation --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index f733d6b7..a1774f4c 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1365,7 +1365,7 @@ TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol) 送信側に正しいレスポンスが返ってこなかったら、パケットを再送信します。タイムアウトが何度も発生したときは、コネクションをdropします。TCP は[フロー制御](https://en.wikipedia.org/wiki/Flow_control_(data)) と [輻輳制御](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control)も実装しています。これらの保証のために遅延が発生するので、一般的に転送効率はUDPより劣ります。 -高スループットを確保するため、ウェブサーバーでは多数のTCPコネクションを開いたままにしておくことがあります。この場合は、メモリーの使用率が高くなります。ウェブサーバのスレッドと、例えば [memcached](#memcached) サーバーの間で多数のコネクションを張ったままにするのは高くつくかもしれません。この場合、可能であればUDPに切り替える、コネクションプーリング[コネクションプーリング](https://en.wikipedia.org/wiki/Connection_pool)を使うといった方法が役立つかもしれません。 +高スループットを確保するため、ウェブサーバーでは多数のTCPコネクションを開いたままにしておくことがあります。この場合は、メモリーの使用率が高くなります。ウェブサーバのスレッドと、例えば [memcached](#memcached) サーバーの間で多数のコネクションを張ったままにするのは高くつくかもしれません。この場合、可能であればUDPに切り替える、[コネクションプーリング](https://en.wikipedia.org/wiki/Connection_pool)を使うといった方法が役立つかもしれません。 TCPは高い依存性を要し、時間制約が厳しくないものに適しているでしょう。ウェブサーバー、データベース情報、SMTP、FTPやSSHなどの例に適用されます。 From 4489d624eb460ebf4b25deafc9fb7738b8a05881 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:32:04 +0900 Subject: [PATCH 08/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "高い依存性を要し" doesn't make sense in this context. - "application" was missing in the translation. - "例に適用されます" doesn't make sense. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index a1774f4c..a7a428c4 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1367,7 +1367,7 @@ TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol) 高スループットを確保するため、ウェブサーバーでは多数のTCPコネクションを開いたままにしておくことがあります。この場合は、メモリーの使用率が高くなります。ウェブサーバのスレッドと、例えば [memcached](#memcached) サーバーの間で多数のコネクションを張ったままにするのは高くつくかもしれません。この場合、可能であればUDPに切り替える、[コネクションプーリング](https://en.wikipedia.org/wiki/Connection_pool)を使うといった方法が役立つかもしれません。 -TCPは高い依存性を要し、時間制約が厳しくないものに適しているでしょう。ウェブサーバー、データベース情報、SMTP、FTPやSSHなどの例に適用されます。 +高い信頼性が必要な一方、応答時間の制約は厳しくないというアプリケーションには、TCPが適しています。例としてはウェブサーバー、データベース情報、SMTP、FTP、SSHなどが挙げられます。 以下の時にUDPよりもTCPを使うといいでしょう: From 734c3a4b67ab58b76337b3b7c4e41fded42b63b1 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:35:18 +0900 Subject: [PATCH 09/42] Make the translation more fluent --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index a7a428c4..fb288453 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1369,7 +1369,7 @@ TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol) 高い信頼性が必要な一方、応答時間の制約は厳しくないというアプリケーションには、TCPが適しています。例としてはウェブサーバー、データベース情報、SMTP、FTP、SSHなどが挙げられます。 -以下の時にUDPよりもTCPを使うといいでしょう: +以下のような場合にはUDPよりもTCPを使うといいでしょう: * 全てのデータが欠損することなしに届いてほしい * ネットワークスループットの最適な自動推測をしてオペレーションしたい From a7f2c50d33d4aad16af33de2e09f99f51352db29 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:35:59 +0900 Subject: [PATCH 10/42] Correct mistranslation The original translation doesn't make sense. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index fb288453..17a13027 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1372,7 +1372,7 @@ TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol) 以下のような場合にはUDPよりもTCPを使うといいでしょう: * 全てのデータが欠損することなしに届いてほしい -* ネットワークスループットの最適な自動推測をしてオペレーションしたい +* ネットワークスループットの利用効率を、予測上の最適値まで自動的に最適化したい ### ユーザデータグラムプロトコル (UDP) From b801eda35b7920e6c66d1d29cc423799586e49c9 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:37:48 +0900 Subject: [PATCH 11/42] Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 17a13027..10d19fea 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1382,7 +1382,7 @@ TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol) Source: How to make a multiplayer game

-UDPはコネクションレスです。データグラム（パケットのようなもの）はデータグラムレベルでの保証しかされません。データグラムは順不同で受け取り先に到着したりそもそも着かなかったりします。UDPは輻輳制御をサポートしません。TCPにおいてはサポートされているこれらの保証がないため、UDPは一般的に、TCPよりも効率的です。 +UDPはコネクションレスです。データグラム（パケットのようなもの）はデータグラムレベルでの保証しかされません。データグラムは順不同で受け取り先に到着したりそもそも着かなかったりします。UDPは輻輳制御をサポートしません。TCPがサポートするこういった保証を行わないため、転送効率については一般的にTCPよりUDPの方が優れています。 UDPはサブネット上のすべての機器にデータグラムを送信することができます。これは[DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) において役に立ちます。というのも、クライアントはまだIPアドレスを取得していないので、IPアドレスを必要とするTCPによるストリームができないからです。 From 98d5ed4a1c18d0dc51590301942294ec5cc80783 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:39:47 +0900 Subject: [PATCH 12/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "ストリームができない" doesn't make sense in this context. - "broadcast" was missing in the translation. - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 10d19fea..fa549adf 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1384,7 +1384,7 @@ TCPは[IP ネットワーク](https://en.wikipedia.org/wiki/Internet_Protocol) UDPはコネクションレスです。データグラム（パケットのようなもの）はデータグラムレベルでの保証しかされません。データグラムは順不同で受け取り先に到着したりそもそも着かなかったりします。UDPは輻輳制御をサポートしません。TCPがサポートするこういった保証を行わないため、転送効率については一般的にTCPよりUDPの方が優れています。 -UDPはサブネット上のすべての機器にデータグラムを送信することができます。これは[DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) において役に立ちます。というのも、クライアントはまだIPアドレスを取得していないので、IPアドレスを必要とするTCPによるストリームができないからです。 +UDPではブロードキャスト（サブネット上のすべての機器にデータグラムを送信すること）ができます。これは[DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol)で役立ちます。というのも、クライアントはまだIPアドレスを取得していないので、IPアドレスを必要とするTCPではデータを流せないからです。 UDPは信頼性の面では劣りますが、VoIP、ビデオチャット、ストリーミングや同時通信マルチプレイヤーゲームなどのリアルタイム性が重視される時にはとても効果的です。 From d8a2800c0e8e3d8807046394203101c845c9cc7f Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:40:47 +0900 Subject: [PATCH 13/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Uniform the translation of "use case(s)" to "ユースケース". - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index fa549adf..af522608 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1386,7 +1386,7 @@ UDPはコネクションレスです。データグラム（パケットのよ UDPではブロードキャスト（サブネット上のすべての機器にデータグラムを送信すること）ができます。これは[DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol)で役立ちます。というのも、クライアントはまだIPアドレスを取得していないので、IPアドレスを必要とするTCPではデータを流せないからです。 -UDPは信頼性の面では劣りますが、VoIP、ビデオチャット、ストリーミングや同時通信マルチプレイヤーゲームなどのリアルタイム性が重視される時にはとても効果的です。 +UDPは信頼性の面では劣りますが、VoIP、ビデオチャット、ストリーミング、リアルタイムマルチプレイヤーゲームなど、リアルタイム性が重視されるユースケースではとても効果的です。 TCPよりもUDPを使うのは: From 33ec78e0c523cb617f599345e087d2a43a40faad Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:41:22 +0900 Subject: [PATCH 14/42] Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index af522608..c6e43a5c 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1388,7 +1388,7 @@ UDPではブロードキャスト（サブネット上のすべての機器に UDPは信頼性の面では劣りますが、VoIP、ビデオチャット、ストリーミング、リアルタイムマルチプレイヤーゲームなど、リアルタイム性が重視されるユースケースではとても効果的です。 -TCPよりもUDPを使うのは: +以下のような場合にはTCPよりもUDPを使うといいでしょう: * レイテンシーを最低限に抑えたい時 * データ欠損よりも、データ遅延を重視するとき From b0c944c4cf2362a59544eab68883e1d4712ecb05 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:43:51 +0900 Subject: [PATCH 15/42] Correct mistranslation. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - The original translation doesn't make sense. - "抽象化する" is more suitable for the translation of "abstractiong" rather than "省く" ("omit"). - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index c6e43a5c..6da66907 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1411,7 +1411,7 @@ UDPは信頼性の面では劣りますが、VoIP、ビデオチャット、ス Source: Crack the system design interview

-RPCではクライアントがリモートサーバーなどの異なるアドレス空間でプロシージャーが処理されるようにします。プロシージャーはローカルでのコールのように、クライアントからサーバーにどのように通信するかという詳細を省いた状態でコードが書かれます。リモートのコールは普通、ローカルのコールよりも遅く、信頼性に欠けるため、RPCコールをローカルコールと区別させておくことが好ましいでしょう。人気のRPCフレームワークは以下です。[Protobuf](https://developers.google.com/protocol-buffers/)、 [Thrift](https://thrift.apache.org/)、[Avro](https://avro.apache.org/docs/current/) +RPCでは、クライアントから別のアドレス空間（通常はリモートサーバー）上で実行される手続きを呼び出します。この処理はローカルでの手続き呼び出しと同じようにコーディングされます。クライアントプログラムがサーバーとどのように通信するかといった詳細は、抽象化により省略されます。リモート呼び出しは普通、ローカルでの呼び出しよりも遅く、信頼性に欠けます。そのため、RPC呼び出しとローカルの手続き呼び出しとは区別がつくようにしておいた方がいいでしょう。よく使われるRPCフレームワークとしては[Protobuf](https://developers.google.com/protocol-buffers/)、 [Thrift](https://thrift.apache.org/)、[Avro](https://avro.apache.org/docs/current/) などがあります。 RPC は リクエストレスポンスプロトコル: From 602940d6d9b766f567ce663f2df22f69434b7fe0 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:49:12 +0900 Subject: [PATCH 16/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Uniform the translation of "local procedure call" to "ローカルでの手続き呼び出し". - "引数" is more suitable for the translation of "arguments" rather than "アーギュメント" (transliteration of "argument"). - "Marshals" was missing in the original translation. - Make the translation more fluent. --- README-ja.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README-ja.md b/README-ja.md index 6da66907..d71a7ba4 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1413,12 +1413,12 @@ UDPは信頼性の面では劣りますが、VoIP、ビデオチャット、ス RPCでは、クライアントから別のアドレス空間（通常はリモートサーバー）上で実行される手続きを呼び出します。この処理はローカルでの手続き呼び出しと同じようにコーディングされます。クライアントプログラムがサーバーとどのように通信するかといった詳細は、抽象化により省略されます。リモート呼び出しは普通、ローカルでの呼び出しよりも遅く、信頼性に欠けます。そのため、RPC呼び出しとローカルの手続き呼び出しとは区別がつくようにしておいた方がいいでしょう。よく使われるRPCフレームワークとしては[Protobuf](https://developers.google.com/protocol-buffers/)、 [Thrift](https://thrift.apache.org/)、[Avro](https://avro.apache.org/docs/current/) などがあります。 -RPC は リクエストレスポンスプロトコル: +RPCはリクエスト・レスポンス型のプロトコルで、以下のように動作します: -* **クライアントプログラム** - クライアントスタブプロシージャーを呼び出します。パラメータはローカルでのプロシージャーコールのようにスタックへとプッシュされていきます。 -* **クライアントスタブプロシージャー** - プロシージャIDとアーギュメントをパックしてリクエストメッセージにします。 -* **クライアント通信モジュール** - OSがクライアントからサーバーへとメッセージを送ります。 -* **サーバー通信モジュール** - OSが受け取ったパケットをサーバースタブプロシージャーに受け渡します。 +* **クライアントプログラム** - クライアントプログラムが、クライアントスタブプロシージャーを呼び出します。パラメータはローカルでの手続き呼び出しのようにスタックへとプッシュされます。 +* **クライアントスタブプロシージャー** - クライアントスタブプロシージャーが、プロシージャIDと引数をマーシャライズ（パック）してリクエストメッセージにします。 +* **クライアント通信モジュール** - クライアント通信モジュールで、OSがクライアントからサーバーへとメッセージを送ります。 +* **サーバー通信モジュール** - サーバー通信モジュールで、OSが受け取ったパケットをサーバースタブプロシージャーに受け渡します。 * **サーバースタブプロシージャー** - 結果を展開し、プロシージャーIDにマッチするサーバープロシージャーを呼び出し、結果を返します。 * サーバーレスポンスは上記のステップを逆順で繰り返します。 From 12a0c4d06521dfa0ce9152394c9e7dc3e14ddf3c Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:50:40 +0900 Subject: [PATCH 17/42] Correct mistranslation. - The original translation meant "Unmarshalls the results, calls the server procedure matching the procedure id, and return the results." - Make the translation more fluent. --- README-ja.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README-ja.md b/README-ja.md index d71a7ba4..bd83c3bc 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1419,8 +1419,8 @@ RPCはリクエスト・レスポンス型のプロトコルで、以下のよ * **クライアントスタブプロシージャー** - クライアントスタブプロシージャーが、プロシージャIDと引数をマーシャライズ（パック）してリクエストメッセージにします。 * **クライアント通信モジュール** - クライアント通信モジュールで、OSがクライアントからサーバーへとメッセージを送ります。 * **サーバー通信モジュール** - サーバー通信モジュールで、OSが受け取ったパケットをサーバースタブプロシージャーに受け渡します。 -* **サーバースタブプロシージャー** - 結果を展開し、プロシージャーIDにマッチするサーバープロシージャーを呼び出し、結果を返します。 -* サーバーレスポンスは上記のステップを逆順で繰り返します。 +* **サーバースタブプロシージャー** - サーバースタブプロシージャーが、受信した内容を展開し、プロシージャーIDにマッチするサーバープロシージャーを呼び出し、与えられた引数を渡します。 +* サーバーがレスポンスを返す際は、上記のステップを逆順で行います。 Sample RPC calls: From 75aa493f7b2d176d85103361f550abef38cbe954 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:51:11 +0900 Subject: [PATCH 18/42] Add omitted translation --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index bd83c3bc..b47f0c36 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1422,7 +1422,7 @@ RPCはリクエスト・レスポンス型のプロトコルで、以下のよ * **サーバースタブプロシージャー** - サーバースタブプロシージャーが、受信した内容を展開し、プロシージャーIDにマッチするサーバープロシージャーを呼び出し、与えられた引数を渡します。 * サーバーがレスポンスを返す際は、上記のステップを逆順で行います。 -Sample RPC calls: +RPC呼び出しの例: ``` GET /someoperation?data=anId From 8c52a68bbae890a853021c5d212094050e4386fa Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:53:13 +0900 Subject: [PATCH 19/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Uniform the translation of "use case(s)" to "ユースケース". - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index b47f0c36..f9dadb6f 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1434,7 +1434,7 @@ POST /anotheroperation } ``` -RPCは振る舞いを公開することに焦点を当てています。RPCは内部通信パフォーマンスを理由として使われることが多いです。というのも、使用する状況に合わせてネイティブコールを自作することができるからです。 +RPCは振る舞いを公開することに焦点を当てています。RPCはそのパフォーマンスを理由に、内部通信においてよく利用されます。場合によっては、ユースケースに合わせてネイティブコールを自作することもできます。 ネイティブライブラリー (aka SDK) を呼ぶのは以下の時: From 8aeae00e2c1222eeba5cc4ccf3d6cc4edda8faff Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:53:59 +0900 Subject: [PATCH 20/42] Correct mistranslation - "aka" was mot translated in the original translation. - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index f9dadb6f..02e26023 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1436,7 +1436,7 @@ POST /anotheroperation RPCは振る舞いを公開することに焦点を当てています。RPCはそのパフォーマンスを理由に、内部通信においてよく利用されます。場合によっては、ユースケースに合わせてネイティブコールを自作することもできます。 -ネイティブライブラリー (aka SDK) を呼ぶのは以下の時: +次のような場合はネイティブライブラリー (SDKとも呼ぶ) を使うほうがいいでしょう: * ターゲットのプラットフォームを知っている時 * ロジックがどのようにアクセスされるのかを管理したいとき From f2dae8a37fec4a9df75b5f59d54481c226cef7e8 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:55:02 +0900 Subject: [PATCH 21/42] Correct mistranslation - quotes were omitted in the original translation. - Make the translation more fluent. --- README-ja.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README-ja.md b/README-ja.md index 02e26023..669fae4e 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1438,10 +1438,10 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは 次のような場合はネイティブライブラリー (SDKとも呼ぶ) を使うほうがいいでしょう: -* ターゲットのプラットフォームを知っている時 -* ロジックがどのようにアクセスされるのかを管理したいとき -* ライブラリー外でエラーがどのようにコントロールされるかを管理したい時 -* パフォーマンスとエンドユーザーエクスペリエンスが最優先の時 +* ターゲットのプラットフォームが分かっているとき +* 「ロジックに」対するアクセス方法を制御したいとき +* ライブラリーの外側でエラーがどのようにコントロールされるかをを制御したいとき +* パフォーマンスとエンドユーザーエクスペリエンスが最優先のとき **REST** プロトコルに従うHTTP APIはパブリックAPIにおいてよく用いられます。 From c6cef9a134e5a5f6ec4d1afea5ecaa209e73feea Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:55:54 +0900 Subject: [PATCH 22/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Uniform the translation of "public APIs" to "公開API". - "more" was omitted in the original translation. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 669fae4e..704ffac0 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1443,7 +1443,7 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは * ライブラリーの外側でエラーがどのようにコントロールされるかをを制御したいとき * パフォーマンスとエンドユーザーエクスペリエンスが最優先のとき -**REST** プロトコルに従うHTTP APIはパブリックAPIにおいてよく用いられます。 +公開APIにおいては、**REST** に基づくHTTP APIの方がよく用いられています。 #### 欠点: RPC From c85c06681cc8afa5910d274547dd35b956af6f9a Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:56:36 +0900 Subject: [PATCH 23/42] Correct mistranslation - The original translation doesn't make sense. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 704ffac0..4bff27af 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1447,7 +1447,7 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは #### 欠点: RPC -* RPCクライアントとはサービス実装により厳密に左右されることになります。 +* RPCクライアントがサービスの実装に密結合してしまいます。。 * 新しいオペレーション、使用例があるたびに新しくAPIが定義されなければなりません。 * RPCをデバッグするのは難しい可能性があります。 * 既存のテクノロジーをそのまま使ってサービスを構築することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/)などのサーバーに[RPCコールが正しくキャッシュ](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように追加で骨を折る必要があるかもしれません。 From 9ec5e03788b7d4c1c87c5390890f15784e726477 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:57:13 +0900 Subject: [PATCH 24/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Uniform the translation of "use case(s)" to "ユースケース". - Make the translation more fluent. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 4bff27af..780d1939 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1448,7 +1448,7 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは #### 欠点: RPC * RPCクライアントがサービスの実装に密結合してしまいます。。 -* 新しいオペレーション、使用例があるたびに新しくAPIが定義されなければなりません。 +* 新しい操作やユースケースができるたびに、新しいAPIを定義しなければなりません。 * RPCをデバッグするのは難しい可能性があります。 * 既存のテクノロジーをそのまま使ってサービスを構築することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/)などのサーバーに[RPCコールが正しくキャッシュ](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように追加で骨を折る必要があるかもしれません。 From 444ddf1ffad16d9ffdaea5c765bede5606c4eb45 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 14:58:45 +0900 Subject: [PATCH 25/42] Make the translation more fluent --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 780d1939..8df1a6de 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1450,7 +1450,7 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは * RPCクライアントがサービスの実装に密結合してしまいます。。 * 新しい操作やユースケースができるたびに、新しいAPIを定義しなければなりません。 * RPCをデバッグするのは難しい可能性があります。 -* 既存のテクノロジーをそのまま使ってサービスを構築することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/)などのサーバーに[RPCコールが正しくキャッシュ](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように追加で骨を折る必要があるかもしれません。 +* 既存のテクノロジーをそのまま活用することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/) などのサーバーに[RPCコールを正しくキャッシュさせる](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) には追加の作業が必要になるかもしれません。 ### Representational state transfer (REST) From 1d0f637fbb7b5ddbe8ed2ea04da171f32ae463a8 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:07:03 +0900 Subject: [PATCH 26/42] Correct mistranslation. - The original translation doesn't make sense. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 8df1a6de..a14ce1b2 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1454,7 +1454,7 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは ### Representational state transfer (REST) -RESTは、クライアントがサーバーによってマネージされるリソースに対して処理を行うクライアント・サーバーモデルを支持するアーキテキチャスタイルです。サーバーは操作できるもしくは新しいリソースレプレゼンテーションを受け取ることができるようなリソースやアクションのレプレゼンテーションを提供します。すべての通信はステートレスでキャッシュ可能でなければなりません。 +RESTはアーキテクチャスタイルの一つで、クライアント・サーバーモデルを推し進めたものです。クライアントは、サーバーが管理しているリソースに対して処理を行います。サーバーはリソースやアクションに対する「表現」(representation) を提供し、クライアントはそれに対する操作を行ったり、新しいリソースの表現を受け取ったりできます。すべての通信はステートレスでキャッシュ可能でなければなりません。 RESTful なインターフェースには次の四つの特徴があります: From e755a2936d5b94d74108434f26c34680e0ca3c81 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:13:25 +0900 Subject: [PATCH 27/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "Identify resources" should be "リソースによって識別される" rather than "特徴的なリソース" ("characteristic resources"). - "URI in HTTP" was not translated in the original translation. - "車輪の再発明" is more commonly used for the translation of "reinvent the wheel" rather than "新しく作る" ("newly develop"). - "status response in HTTP" was not translated in the original translation. - "自分の" ("your") should be omitted in the translation. - "HTML interface for HTTP" was not translated in the original translation. --- README-ja.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README-ja.md b/README-ja.md index a14ce1b2..5e543c30 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1458,10 +1458,10 @@ RESTはアーキテクチャスタイルの一つで、クライアント・サ RESTful なインターフェースには次の四つの特徴があります: -* **特徴的なリソース (URI in HTTP)** - どのオペレーションであっても同じURIを使う。 -* **HTTP動詞によって変わる (Verbs in HTTP)** - 動詞、ヘッダー、ボディを使う -* **自己説明的なエラーメッセージ (status response in HTTP)** - ステータスコードを使い、新しく作ったりしないこと。 -* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML interface for HTTP)** - 自分のwebサービスがブラウザで完全にアクセスできること。 +* **リソース(HTTPにおけるURI)によって識別される** - どのオペレーションであっても同じURIを使うこと。 +* **表現(HTTPにおける動詞)によって変化する** - 動詞、ヘッダー、ボディを使うこと。 +* **自己説明的なエラーメッセージ (HTTPにおけるステータスレスポンス)** - ステータスコードを使うこと。車輪の再発明はしないこと。 +* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTTPにおけるHTMLインタフェース)** - Webサービスがブラウザから完全にアクセスできること。 サンプル REST コール: From ce24b74b39b8f45fe841c99e155f8952a8b1249e Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:13:57 +0900 Subject: [PATCH 28/42] Make the translation more fluent --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 5e543c30..58d66aac 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1463,7 +1463,7 @@ RESTful なインターフェースには次の四つの特徴があります: * **自己説明的なエラーメッセージ (HTTPにおけるステータスレスポンス)** - ステータスコードを使うこと。車輪の再発明はしないこと。 * **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTTPにおけるHTMLインタフェース)** - Webサービスがブラウザから完全にアクセスできること。 -サンプル REST コール: +REST呼び出しの例: ``` GET /someresources/anId From 78c1dd7e7071644645b155cd10b73c861ad3ffa0 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:16:58 +0900 Subject: [PATCH 29/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - The original translation doesn't make sense. - Translation for "coupling" should be "結合度" in this context, rather than "カップリング". - Uniform the translation of "public APIs" to "公開API". --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 58d66aac..125e9919 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1472,7 +1472,7 @@ PUT /someresources/anId {"anotherdata": "another value"} ``` -RESTはデータを公開することに焦点を当てています。クライアントとサーバーのカップリングを最小限にするもので、パブリックAPIなどによく用いられます。RESTはURI、 [representation through headers](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)、そして、GET、POST、PUT、 DELETE、PATCHなどのHTTP動詞等のよりジェネリックで統一されたメソッドを用います。ステートレスであるのでRESTは水平スケーリングやパーティショニングに最適です。 +RESTはデータを公開することに焦点を当てています。RESTではクライアントとサーバーの結合度を最小にでき、公開APIなどによく用いられます。RESTでは、リソースの公開にはURI、リソースの[表現にはHTTPヘッダー](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)、アクションにはHTTP動詞（GET, POST, PUT, DELETE, PATCH）といったように、そのそれぞれに対してより一般的で統一された方法を用います。RESTはステートレスなので、水平スケーリングやパーティショニングに最適です。 #### 欠点: REST From e7c2e0e20aba4d1f07476a4b01d42fc597ec7681 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:18:19 +0900 Subject: [PATCH 30/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Translation for "updated records" should be "更新されたレコード" rather than "更新情報". - "the past hour" was omitted in the original translation. - "a combination of" was omitted in the original translation. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 125e9919..b06fa0f2 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1476,7 +1476,7 @@ RESTはデータを公開することに焦点を当てています。RESTでは #### 欠点: REST -* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、とあるイベントのセットにマッチするすべての更新情報を返すと言った処理は簡単にはパスで表現することができません。RESTでは、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどによって実装されることが多いでしょう。 +* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。 * RESTは少数の動詞に依存しています(GET、POST、PUT、DELETE、そして PATCH) が時には使いたい事例に合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。 * ネストされたヒエラルキーの中にあるリソースをとってくるのはシングルビューを描画するのにクライアントとサーバー間で数回やりとりしなければなりません。例として、ブログエントリーのコンテンツとそれに対するコメントを表示する場合などです。様々なネットワーク環境で動作する可能性が考えられるモバイルアプリケーションにおいてはこのような複数のやり取りは好ましくありません。 * 時が経つにつれて、APIレスポンスにより多くのフィールドが与えられて、古いクライアントはすでにいらないものも含めてすべてのデータフィールドを受け取ることになります。そのことで、ペイロードが大きくなりすぎて、レイテンシーも拡大することになります。 From ba02ebee2c04de5994b88e45a703e3706b9902dd Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:19:53 +0900 Subject: [PATCH 31/42] Correct mistranslation - The original translation doesn't make sense. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index b06fa0f2..83f19b05 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1477,7 +1477,7 @@ RESTはデータを公開することに焦点を当てています。RESTでは #### 欠点: REST * RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。 -* RESTは少数の動詞に依存しています(GET、POST、PUT、DELETE、そして PATCH) が時には使いたい事例に合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。 +* 一般的に、RESTでは限られたHTTP動詞のみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。 * ネストされたヒエラルキーの中にあるリソースをとってくるのはシングルビューを描画するのにクライアントとサーバー間で数回やりとりしなければなりません。例として、ブログエントリーのコンテンツとそれに対するコメントを表示する場合などです。様々なネットワーク環境で動作する可能性が考えられるモバイルアプリケーションにおいてはこのような複数のやり取りは好ましくありません。 * 時が経つにつれて、APIレスポンスにより多くのフィールドが与えられて、古いクライアントはすでにいらないものも含めてすべてのデータフィールドを受け取ることになります。そのことで、ペイロードが大きくなりすぎて、レイテンシーも拡大することになります。 From 5d3303dc44d7c23097b8df04fd56cfa0cb570c28 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:21:02 +0900 Subject: [PATCH 32/42] Correct mistranslation. - The original translation doesn't make sense. --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 83f19b05..db03551c 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比較 From b0e17de5ddadc6e9b3f1d6de20e29210bd1f2ed2 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:21:40 +0900 Subject: [PATCH 33/42] Make the translation more fluent --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index db03551c..293712a8 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1479,7 +1479,7 @@ RESTはデータを公開することに焦点を当てています。RESTでは * RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。 * 一般的に、RESTでは限られたHTTP動詞のみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。 * 入れ子になった階層構造を持つ、複雑なリソースを取得する場合、一つのビューを描画するだけでもクライアントとサーバーの間で複数回のやりとりが発生します。例えば、ブログのエントリーの内容と、それに対するコメントを取得する場合が該当します。様々なネットワーク環境で動作するようなモバイルアプリケーションにおいては、このようなやり取りが複数回発生するのは非常に好ましくありません。 -* 時が経つにつれて、APIレスポンスにより多くのフィールドが与えられて、古いクライアントはすでにいらないものも含めてすべてのデータフィールドを受け取ることになります。そのことで、ペイロードが大きくなりすぎて、レイテンシーも拡大することになります。 +* 時が経つにつれて、APIレスポンスにはより多くのフィールドが追加されていきます。この際、古くからあるクライアントは、追加されたフィールドを使いもしないのにすべて受け取ることになります。結果として、ペイロードも膨れますし、レイテンシーも拡大することになります。 ### RPCとREST比較 From a1976b2bfa027369de2cce4620959fd8382e14d6 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:24:46 +0900 Subject: [PATCH 34/42] Make the translation more fluent --- README-ja.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README-ja.md b/README-ja.md index 293712a8..83133324 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1481,17 +1481,17 @@ RESTはデータを公開することに焦点を当てています。RESTでは * 入れ子になった階層構造を持つ、複雑なリソースを取得する場合、一つのビューを描画するだけでもクライアントとサーバーの間で複数回のやりとりが発生します。例えば、ブログのエントリーの内容と、それに対するコメントを取得する場合が該当します。様々なネットワーク環境で動作するようなモバイルアプリケーションにおいては、このようなやり取りが複数回発生するのは非常に好ましくありません。 * 時が経つにつれて、APIレスポンスにはより多くのフィールドが追加されていきます。この際、古くからあるクライアントは、追加されたフィールドを使いもしないのにすべて受け取ることになります。結果として、ペイロードも膨れますし、レイテンシーも拡大することになります。 -### RPCとREST比較 +### RPCとRESTの比較 -| Operation | RPC | REST | +| 操作 | RPC | REST | |---|---|---| | サインアップ | **POST** /signup | **POST** /persons | -| リザイン | **POST** /resign
{
"personid": "1234"
} | **DELETE** /persons/1234 | -| Person読み込み | **GET** /readPerson?personid=1234 | **GET** /persons/1234 | -| Personのアイテムリスト読み込み | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items | -| Personのアイテムへのアイテム追加 | **POST** /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | **POST** /persons/1234/items
{
"itemid": "456"
} | -| アイテム更新 | **POST** /modifyItem
{
"itemid": "456";
"key": "value"
} | **PUT** /items/456
{
"key": "value"
} | -| アイテム削除 | **POST** /removeItem
{
"itemid": "456"
} | **DELETE** /items/456 | +| 退会 | **POST** /resign
{
"personid": "1234"
} | **DELETE** /persons/1234 | +| 個人データの読み込み | **GET** /readPerson?personid=1234 | **GET** /persons/1234 | +| 個人のアイテムリスト読み込み | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items | +| 個人のアイテムリストへアイテムを追加 | **POST** /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | **POST** /persons/1234/items
{
"itemid": "456"
} | +| アイテムの更新 | **POST** /modifyItem
{
"itemid": "456";
"key": "value"
} | **PUT** /items/456
{
"key": "value"
} | +| アイテムの削除 | **POST** /removeItem
{
"itemid": "456"
} | **DELETE** /items/456 |

Source: Do you really know why you prefer REST over RPC From 1bc4182995a2257fc32a125897431bc27402a6ef Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:30:25 +0900 Subject: [PATCH 35/42] Make translation more fluent --- README-ja.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README-ja.md b/README-ja.md index 83133324..ec738805 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1328,19 +1328,19 @@ def set_user(user_id, values): ### Hypertext transfer protocol (HTTP) -HTTPはリクエスト・レスポンス型のプロトコルです。クライアントがリクエストを投げると、サーバーはそのリクエストに対応するコンテンツと完了ステータスの情報をレスポンスとして返します。HTTPは自己完結したプロトコルです。リクエストやレスポンスが数多くのサーバーやルーターを通過し、その間にロードバランシング、キャッシュ、暗号化、圧縮などが行われていても、問題なく動くようにできています。 +HTTPはリクエスト・レスポンス型のプロトコルです。クライアントがリクエストを投げると、サーバーはそのリクエストに対応するコンテンツと完了ステータスをレスポンスとして返します。HTTPは自己完結したプロトコルです。リクエストやレスポンスが数多くのサーバーやルーターを通過し、その間にロードバランシング、キャッシュ、暗号化、圧縮などが行われていても、問題なく動くようにできています。 -基本的なHTTPリクエストはHTTP動詞(メソッド)とリソース(エンドポイント)で成り立っています。以下がよくあるHTTP動詞です。: +基本的なHTTPリクエストはHTTP動詞(メソッド)とリソース(エンドポイント)で成り立っています。よく使われるHTTP動詞としては以下のものが挙げられます: | 動詞 | 詳細 | 冪等性* | セーフ | キャッシュできるか | |---|---|---|---|---| | GET | リソースを読み取る | Yes | Yes | Yes | -| POST | リソースを作成するもしくはデータを処理するトリガー | No | No | Yes レスポンスが新しい情報を含む場合 | +| POST | リソースを作成する、データを処理するプロセスをトリガーする | No | No | Yes レスポンスが新しい情報を含む場合 | | PUT | リソースを作成もしくは入れ替える | Yes | No | No | | PATCH | リソースを部分的に更新する | No | No | Yes レスポンスが新しい情報を含む場合 | | DELETE | リソースを削除する | Yes | No | No | -*何度呼んでも同じ結果が返ってくること* +* 何度呼んでも同じ結果が返ってくること HTTPはアプリケーション層のプロトコルで、**TCP** や **UDP** など下位のプロトコルの上で動作します。 From af99a7c9afe72a06b5f38a6e18b4144e0ce77134 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:31:03 +0900 Subject: [PATCH 36/42] Make translation more fluent --- README-ja.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README-ja.md b/README-ja.md index ec738805..1bfa36ba 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1335,12 +1335,12 @@ HTTPはリクエスト・レスポンス型のプロトコルです。クライ | 動詞 | 詳細 | 冪等性* | セーフ | キャッシュできるか | |---|---|---|---|---| | GET | リソースを読み取る | Yes | Yes | Yes | -| POST | リソースを作成する、データを処理するプロセスをトリガーする | No | No | Yes レスポンスが新しい情報を含む場合 | +| POST | リソースを作成する、またはデータを処理するプロセスをトリガーする | No | No | Yes レスポンスが新しい情報を含む場合 | | PUT | リソースを作成もしくは入れ替える | Yes | No | No | | PATCH | リソースを部分的に更新する | No | No | Yes レスポンスが新しい情報を含む場合 | | DELETE | リソースを削除する | Yes | No | No | -* 何度呼んでも同じ結果が返ってくること +*何度呼んでも同じ結果が返ってくること HTTPはアプリケーション層のプロトコルで、**TCP** や **UDP** など下位のプロトコルの上で動作します。 From 3f3f3c20a53e233f9a58b4273e58d5b0c8571955 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:33:54 +0900 Subject: [PATCH 37/42] Correct mistranslation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "メムキャッシュ" is overtranslation of "memcache". --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index 1bfa36ba..eefebd1e 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1401,7 +1401,7 @@ UDPは信頼性の面では劣りますが、VoIP、ビデオチャット、ス * [TCP と UDPの違い](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp) * [Transmission control protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) * [User datagram protocol](https://en.wikipedia.org/wiki/User_Datagram_Protocol) -* [Facebookのメムキャッシュスケーリング](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf) +* [Facebookにおけるmemcacheのスケーリング](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf) ### 遠隔手続呼出 (RPC) From 5601b4b400b2618ca6d0e6b3cc6a016ee0475507 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Mon, 21 Oct 2019 15:35:18 +0900 Subject: [PATCH 38/42] Fix typo --- README-ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-ja.md b/README-ja.md index eefebd1e..e13a5599 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1447,7 +1447,7 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは #### 欠点: RPC -* RPCクライアントがサービスの実装に密結合してしまいます。。 +* RPCクライアントがサービスの実装に密結合してしまいます。 * 新しい操作やユースケースができるたびに、新しいAPIを定義しなければなりません。 * RPCをデバッグするのは難しい可能性があります。 * 既存のテクノロジーをそのまま活用することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/) などのサーバーに[RPCコールを正しくキャッシュさせる](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) には追加の作業が必要になるかもしれません。 From a8354e9040d8217175819693d29aa11713368f53 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Sat, 8 Feb 2020 18:03:23 +0900 Subject: [PATCH 39/42] Update README-ja.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change "動詞" to "メソッド" according to RFC --- README-ja.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README-ja.md b/README-ja.md index e13a5599..c5d3c2c7 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1330,9 +1330,9 @@ def set_user(user_id, values): HTTPはリクエスト・レスポンス型のプロトコルです。クライアントがリクエストを投げると、サーバーはそのリクエストに対応するコンテンツと完了ステータスをレスポンスとして返します。HTTPは自己完結したプロトコルです。リクエストやレスポンスが数多くのサーバーやルーターを通過し、その間にロードバランシング、キャッシュ、暗号化、圧縮などが行われていても、問題なく動くようにできています。 -基本的なHTTPリクエストはHTTP動詞(メソッド)とリソース(エンドポイント)で成り立っています。よく使われるHTTP動詞としては以下のものが挙げられます: +基本的なHTTPリクエストはHTTPメソッド(動詞)とリソース(エンドポイント)で成り立っています。よく使われるHTTPメソッドとしては以下のものが挙げられます: -| 動詞 | 詳細 | 冪等性* | セーフ | キャッシュできるか | +| メソッド | 詳細 | 冪等性* | セーフ | キャッシュできるか | |---|---|---|---|---| | GET | リソースを読み取る | Yes | Yes | Yes | | POST | リソースを作成する、またはデータを処理するプロセスをトリガーする | No | No | Yes レスポンスが新しい情報を含む場合 | @@ -1459,7 +1459,7 @@ RESTはアーキテクチャスタイルの一つで、クライアント・サ RESTful なインターフェースには次の四つの特徴があります: * **リソース(HTTPにおけるURI)によって識別される** - どのオペレーションであっても同じURIを使うこと。 -* **表現(HTTPにおける動詞)によって変化する** - 動詞、ヘッダー、ボディを使うこと。 +* **表現(HTTPにおけるメソッド)によって変化する** - メソッド、ヘッダー、ボディを使うこと。 * **自己説明的なエラーメッセージ (HTTPにおけるステータスレスポンス)** - ステータスコードを使うこと。車輪の再発明はしないこと。 * **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTTPにおけるHTMLインタフェース)** - Webサービスがブラウザから完全にアクセスできること。 @@ -1472,12 +1472,12 @@ PUT /someresources/anId {"anotherdata": "another value"} ``` -RESTはデータを公開することに焦点を当てています。RESTではクライアントとサーバーの結合度を最小にでき、公開APIなどによく用いられます。RESTでは、リソースの公開にはURI、リソースの[表現にはHTTPヘッダー](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)、アクションにはHTTP動詞（GET, POST, PUT, DELETE, PATCH）といったように、そのそれぞれに対してより一般的で統一された方法を用います。RESTはステートレスなので、水平スケーリングやパーティショニングに最適です。 +RESTはデータを公開することに焦点を当てています。RESTではクライアントとサーバーの結合度を最小にでき、公開APIなどによく用いられます。RESTでは、リソースの公開にはURI、リソースの[表現にはHTTPヘッダー](https://github.com/for-GET/know-your-http-well/blob/master/headers.md)、アクションにはHTTPメソッド（GET, POST, PUT, DELETE, PATCH）といったように、そのそれぞれに対してより一般的で統一された方法を用います。RESTはステートレスなので、水平スケーリングやパーティショニングに最適です。 #### 欠点: REST * RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。 -* 一般的に、RESTでは限られたHTTP動詞のみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。 +* 一般的に、RESTでは限られたHTTPメソッドのみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらのメソッドには綺麗にはフィットしません。 * 入れ子になった階層構造を持つ、複雑なリソースを取得する場合、一つのビューを描画するだけでもクライアントとサーバーの間で複数回のやりとりが発生します。例えば、ブログのエントリーの内容と、それに対するコメントを取得する場合が該当します。様々なネットワーク環境で動作するようなモバイルアプリケーションにおいては、このようなやり取りが複数回発生するのは非常に好ましくありません。 * 時が経つにつれて、APIレスポンスにはより多くのフィールドが追加されていきます。この際、古くからあるクライアントは、追加されたフィールドを使いもしないのにすべて受け取ることになります。結果として、ペイロードも膨れますし、レイテンシーも拡大することになります。 From 959ba53516c3d40dc99e14782d7b06398ce07706 Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 13 Feb 2020 02:14:09 +0900 Subject: [PATCH 40/42] 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 c5d3c2c7..c13f890e 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1458,7 +1458,7 @@ RESTはアーキテクチャスタイルの一つで、クライアント・サ RESTful なインターフェースには次の四つの特徴があります: -* **リソース(HTTPにおけるURI)によって識別される** - どのオペレーションであっても同じURIを使うこと。 +* **リソースの一意性(HTTPにおけるURI)** - どのオペレーションであっても同じURIを使うこと。 * **表現(HTTPにおけるメソッド)によって変化する** - メソッド、ヘッダー、ボディを使うこと。 * **自己説明的なエラーメッセージ (HTTPにおけるステータスレスポンス)** - ステータスコードを使うこと。車輪の再発明はしないこと。 * **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTTPにおけるHTMLインタフェース)** - Webサービスがブラウザから完全にアクセスできること。 From ca5fd9deff7e269ef24920b5ba822b63772c33be Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 13 Feb 2020 02:15:34 +0900 Subject: [PATCH 41/42] 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 c13f890e..3ff0d5da 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1476,7 +1476,7 @@ RESTはデータを公開することに焦点を当てています。RESTでは #### 欠点: REST -* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。 +* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルな階層構造で表せない時にはよい選択肢とは言えないかもしれません。例えば、ある複数のイベントで直近1時間に更新されたすべてのレコードを返すといった処理を、パスとして表現するのは簡単ではありません。RESTではこのような場合、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどの組み合わせで実装することになるでしょう。 * 一般的に、RESTでは限られたHTTPメソッドのみ(GET、POST、PUT、DELETE、PATCH)を使いますが、これがユースケースに合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらのメソッドには綺麗にはフィットしません。 * 入れ子になった階層構造を持つ、複雑なリソースを取得する場合、一つのビューを描画するだけでもクライアントとサーバーの間で複数回のやりとりが発生します。例えば、ブログのエントリーの内容と、それに対するコメントを取得する場合が該当します。様々なネットワーク環境で動作するようなモバイルアプリケーションにおいては、このようなやり取りが複数回発生するのは非常に好ましくありません。 * 時が経つにつれて、APIレスポンスにはより多くのフィールドが追加されていきます。この際、古くからあるクライアントは、追加されたフィールドを使いもしないのにすべて受け取ることになります。結果として、ペイロードも膨れますし、レイテンシーも拡大することになります。 From fa199a68b8a02ad8b14bb28f2c402d707e04c1da Mon Sep 17 00:00:00 2001 From: SATO Yusuke Date: Thu, 13 Feb 2020 02:19:47 +0900 Subject: [PATCH 42/42] 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の比較