Zenn
👏

「webを支える技術」を読んで興味深かった箇所をピックアップ

2022/01/15に公開
Web
http
rest
idea

エンジニアとして働き始めて少し経った頃に、「Webを支える技術」を読みました。

Webの入門書としては2冊目だったのですが、1冊目には書かれておらず、かつ検索してもなかなかリーチしずらそうな面白い内容が多数ありましたので、それらをピックアップしていきます^^。

SOAP 対 REST

Webアーキテクチャの標準化における大きな論争

RESTの台頭

元々は当時カルフォルニア大学の大学院生だったら人が、分析と研究をして１つのアーキテクチャスタイルをRESTを名付けて論文として提出したのが始まり。

RESTの提唱者が大ベンダーが推進するSOAPベースの技術を否定し、WebがWebらしくあるためのアーキテクチャスタイルとしてRESTを推奨するが、一人の研究者と大手ベンダーでは政治的な力の差が歴然としていて、声が届かない。

RESTの普及に弾みを付けたのは2002年に登場したAmazon Webサービス

Amazonは、自社が扱う書籍やそのほかの商品の情報を Webを通じてプログラムから取得できるようにした。その際にSOAP形式と、RESTのような形式で提供した。

AmazonのWeb APIは、その情報の有用性と扱いの簡単さから、瞬く間に普及したが、SOAP形式とREST形式の利用比率が20対80であるという報告がなされたとき、SOAP 対 RESTの論争に火が付いた。

RESTを否定する人々の主張

主張内容は以下

「Amazonのようにセキュリティが必要ない簡単な Web APIでは、URIをGETするだけのシンプルな方式のほうが利用される。しかし、基幹システムなどでトランザクションや信頼性が必要なときは、RESTでは機能が不十分である」

筆者曰く最終的には意地の張り合いになって「RESTはおもちゃ」っていう言説もあったらしいw

「RESTはおもちゃ」に対して筆者の解釈は以下

この言葉の陰にはWeb APIを作っているWebベンチャーなどの技術者に対する、旧来のエンジニアからの侮蔑の意味が込められていたのではないでしょうか。「HTTPやURIだけで基幹システムが作れるのか?」「そんなものおもちゃでしかないじゃないか」と。

RESTが勝つ

しかし最終的にはRESTが勝つ。
2004年から始まった Web2.0の流れの中で、GoogleやAmazonといった企業は REST形式のWeb APIを提供し始める。

要因

  • Web 2.0 で重要だったのはマッシュアップ
  • マッシュアップ = Web APIが提供するいろいろな情報を組み合わせて1つのアプリケーションを実現する手法
  • マッシュアップでは手軽さが求められたため、簡単に操作できるRESTのほうが受け入れられた

SOAPの敗因

筆者曰く2個

複雑性

RPC/分散オブジェクトが持っていた技術的な問題点をそのまま継承して、さらに複雑にした仕様群になった。

  • ベンダー間でのインタフェース互換性の欠如
  • 複雑なプロトコルスタック
  • ネットワーク越しのインタフェース呼び出しによるオーバーヘッド

政治的な理由

SOAPやWS-*の標準化作業は W3CやOASISで行われた。
ここでの標準化作業は、各ベンダーがドラフトを持ち寄って差異を調整する形で行われました。しかし多くのベンダーがSOAP自体も標準として確定していないうちに実装を進めたため、同じSOAPやWS-*でも解釈に違いが生じ、相互運用性に欠けてしまいました。

webの成長が凄まじかったからSOAPの使用が標準化する前に、各社がそれぞれのやり方でやっちゃってて、各社が自社の標準を通そうと標準化競争が起きてたらしい。

URLは変わりにくくした方がいい

リンク集を作ったのに、時間が経って404になってしまったら、良くない。
これはwebを根幹を揺るがす問題。

「URIは変わらないべきである。変わらないURIこそが最上のURIでさる」

  • 言語に依存した拡張子やパスを避ける
  • メソッド名やセッション名を含めない
  • URLはリソースを表現する名詞にする
sample/people/show/123

showは動詞。これはいらない。

webのステートレス性について

クライアント = ブラウザなど

ステートフルの欠点

スケールアウトがしにくい

負荷分散や冗長化などでサーバーを複数台立てた場合、サーバー間でアプリケーション状態を共有する必要があるが、データを同期するオーバーヘッドが生じてしまう

サーバがクライアントのアプリケーション状態を覚えることは、クライアントの数が増えるにしたがって難しくなっていきます。このようにステートフルなアーキテクチャでは、クライアントの数が増えた場合にスケールアウトさせにくくなります。1つのサーバが同時にクライアントに接続できる数には限りがあるため、サーバーを複数台立てて分散します。その場合、複数のサーバ間でアプリケーション状態を同期して、どのサーバでも同じアプリケーション状態を扱えるようにしなければなりません。

ステートレスの利点

  • ステートレスは上記の問題を解決するべく、アプリケーション状態をサーバではなくクライアント自体が記憶しておく
  • そうするとサーバーは新しいリクエストを処理することに集中できる

ステートレスの欠点

パフォーマンスの低下

  • サーバーへのリクエストが冗長になり、データ送信量が増える
  • 認証などサーバーに負荷のかかる処理を繰り返す

通信エラーへの対処

通信エラーなどでリクエストが中断されたときに、サーバーはそのリクエストが受理されたのかどうかを知らない。

例えば、商品を注文する処理の途中で切断された場合。
ステートフルの場合、サーバーが既に注文を処理されたのかわかる
ステートレスの場合、サーバーが既に注文を処理したのか知らないため、二重で注文されてしまう。

HTTPメソッド

8つのメソッドがあるのにも関わらず、多用されているのはGET,POST。
なぜかというと、HTMlのフォームで指定できるメソッドがGET,POSTであるから。

ただHTMLフォームであっても、_methodパラメータやX-HTTP-Method-Overrideで、その他のメソッドを使用できる。

各メソッドの性質について

各メソッドには、べき等性と安全性という性質があるので誤用を防ごう。
webサービスやAPIで設計を誤るとこれらのメソッドの性質が守られなくなってしまい、ギョッとする。

メソッド べき等性 安全性
GET ,POST ○ ○
PUT,DELETE ○ ×
POST × ×

べき等性

べき等性 = ある操作を行っても結果が同じこと
PUTとDELETEはべき等性だから、何度同じリソースを発行しても同じ結果になるように設計すべき

安全性

安全性 = 操作対象のリソースに副作用がないこと
GETは副作用がないため、GETを同じリソースを何回発行してもリソースの状態は変化しない。

ステータスコード

返すステータスコードを適当にすると、困ることがある。
例えば404のところを200と返していると、検索エンジンのロボットが正常なページを判断してインデックス処理が行われてしまうかも。

jsonについて

  • JSON = javascript Object Notation
  • RFC4627が規程するデータ記述言語。
  • リソース表現の一つ。
  • 他にはHTML、microformats,Atomなどがあるが、それらよりも軽量

データ型

配列

["aaa","bbb","ccc"]

文字列

"hello my frined"

数値

-22

ブーリアン

リテラルで用意されてる

リテラル (literal)とは

null

上に同じ

オブジェクト

{ 
    "name" : {
        "first" : "sato"
        "last" : "shira"
    },
    "age" : 22,
    "interests" : ["Laravel",Vue.js"]
}

最後に

SOAPとRESTを支持する人たちの対立構造のなかで、筆者曰く最終的には意地の張り合いになってたっていうのが面白かったです。「RESTはおもちゃ」ってパワーワードですね。SOAPが廃れていった要因の一つに各ベンダーの政治的なムーブが影響していたというのも興味深いです。

Webのステートレス性について章はめっちゃ勉強になりました。

Discussion