[2022年8月号] Software Design(技術評論社) サマリー+個人メモ

Software Design の2022年8月号について、

ざっくり内容紹介
個人的に気になった記事やポイント

をまとめている記事です。

サマリー記事の一覧はこちら。

特集①：Web APIの作り方
特集②：WebエンジニアのためのDNS速習講座
Development
Software Design 2022年8月号

特集①：Web APIの作り方

Web APIの目的と技術要素
- ProgrammableWebなるサイトにAPI情報の収集データがあり、登録数がめっちゃ増えてる
  - こんなん全然あてになんなそうだけど…
- アプリケーションプログラミングインターフェースのAPIとの違い
  - 結局は「Web APIはHTTPでやりとるするAPI」みたいな理解でいいとここにも書いてある
- 最低限守ること：
  - RestfulAPI、状態を持たずに冪等性を担保する
  - パスに動詞（特にHTTPメソッドのワード）を入れない
  - ページネーションを示す返却値
- OpenAPI
  - もう標準といってよい
- Postmanなどのツール
REST APIの設計で検討・決定すること
- クライアントとサーバーがある
- ステートレスにする
- キャッシュをする
  - クライアントは常にレスポンスをキャッシュできるという前提に立つのがいいらしい
- 統一インターフェース：次の４つを満たすもの
  - リソースの識別
    - サーバー側にある各種データなどをURIで識別できるか
  - 表現を用いたリソース操作
    - 表現とはペイロード部分のこと、これによってリソースを操作できること（つまり普通に作れば満たす）。
  - 自己記述メッセージ
    - メッセージとはリクエストやレスポンスのこと、データが自分で自分を表しているかということになる
  - HATEOAS
    - Hypermedia as the Engine of Application State、「ページネーションの次を返しましょう」みたいなことらしい
- メソッドの使い分け
  - 特にPOSTとPUT
    - URIが特定されない新規作成はPOST、既にURIが特定されているものはPUTという定義がよさそう（結局CreateかUpdateかになるけど）
- APIに複数バージョンを併存させる場合
  - 「リソースを表現するものではない」という考え方からバージョンはヘッダーに含めてもらうようにするのがよいとのこと、これは覚えておきたい
- レスポンス
  - オブジェクトはフラットにする
    - あんまりまとめちゃいけないってこと？これはあまり実感がないけど言われてみればそんな気はするしアプリケーション側も階層のあるオブジェクトにはなるべく触れたくないから正解なのかも、覚えておきたい
OpenAPIによるREST API設計
- 飛ばします

特集②：WebエンジニアのためのDNS速習講座

DNSとは
- 30年以上前に決められた仕組みのまま今も動いている、すごい
- IPアドレスをいっぱい覚えるのが大変だからURLアドレスから変換できるようにしよう！の会
  - でもこれ今思うとさ、実際はググってサイトを見つけてブックマークするわけで、多くのエンドユーザーはURLすら見ていないよね。実はいらないのでは…？
- 大きな流れ：foo.example.comの場合
  - ROOTサーバーにまず問い合わせる。すべてのTLDの権威サーバ情報を持っているサーバなので「.comはあっち、.jpはあっちいけ」みたいにできる
  - 各TLDの権威サーバとやらにいく、example.comの情報をもらう
  - ここで到達するのがRoute53みたいないつものDNSサーバー
DNSの構成要素と名前解決のしくみ
- ドメインに関する基本用語集みたいのもあったので新人教育などにもいいかも
  - ゾーン：ドメインを管理する単位！
  - 各種DNSレコードももちろん！
現在のDNS事情とセキュリティ
- 古くからほぼ同じ仕組みではあるが、さすがに修正や拡張は継続的に繰り返されている
- セキュリティについて
  - キャッシュポイズニング
    - 主にUDPを使う関係で、ステートフルチックにするために個別のIDをリクエストとレスポンス間でシンプルにやりとりしている。でもこのIDが16ビット（65536）しかないために攻撃に弱い、これをキャッシュポイズニングという
      - 対策：ソースポートランダマイゼーション、「ソースポート」（いつものポートと違うもの？）の65536通りも合わせることで42億通りのランダムにする
      - 対策：UDPではなくTCPを使う
  - 中間者攻撃と経路ハイジャック
    - HTTPやTelnetがいまは安全ではないものとして認識されたのと同様、ただランダムにして的を増やすだけではDNSも安全にはならない
    - TLSがあればブラウザは少なくとも警告を出せる（2018年のMyEtherWallet事件では警告を無視したユーザーだけが被害にあった）
      - でもCAとの間で中間者攻撃できてしまったらそれすら無理になる
    - DNSSEC
      - ここで登場するのがこいつ、RPKIとかのやつ
      - DNSSECはユーザー側でできること（RPKIは回線事業者側の普及を待たないといけないこと）
      - DNSに登録する情報に電子署名を加えるもの
    - DNSトランスポート暗号化
      - DNSに登録される情報はもともと公開されるものなので「盗聴されないこと」には主眼が置かれていなかった
        
        DNSSECも通信自体は平文
      - スノーデン事件でプライバシーの重要度が上がるとトランスポートの暗号化も行われるようになっていった
        
        要は下位層が暗号化されることでDNSもその恩恵を受けるようになったということ、これがいわゆるDNS over HTTPS（DoH）になる