/league」という新しいエンドポイントを作成します。彼女はこれがJSONとして返されることを望んでいます。/league」テーブルのエンドポイントを作成します。PlayerStoreを使用するため、既存のスイートを拡張します。/leagueを押してOKが返されることを確認することです。PlayerServer は 404 Not Found を返し、まるで未知のプレイヤーの勝利を得ようとしているかのようです。server.go がどのように ServeHTTP を実装しているかを見てみると、常に特定のプレイヤーを指す URL で呼び出されることを想定していることが分かります。xのパスにはyハンドラを使用するように指示します。http.HandlerFuncを使用し、/leagueがリクエストされたときに w.WriteHeader(http.StatusOK) を指定する anonymous function を使用して、新しいテストをパスするようにします。/players/のルートについては、コードを切り取り、別のhttp.HandlerFuncに貼り付けています。ServeHTTP を呼び出して、リクエストを処理します。ServeHTTPはかなり大きく見えます。ハンドラを別のメソッドにリファクタリングすることで、物事を少し分離することができます。NewPlayerServer関数を持っていて、依存関係を取り込んで、 ルータを作成するための一度きりのセットアップを行うことです。それぞれのリクエストはそのルーターのインスタンスを使うだけです。PlayerServerはルータを保存する必要があります。ServeHTTPからNewPlayerServerに移動したので、これはリクエストごとではなく一度だけで済みます。NewPlayerServer(&store)で PlayerServer{&store}を実行するために使用していたすべてのテストおよび製品コードを更新する必要があります。server_test.go, server_integration_test.go, main.go 内の server := &PlayerServer{&store} を server := NewPlayerServer(&store) に置き換えてみてください。func (p *PlayerServer) ServeHTTP(w http.ResponseWriter, r *http.Request)が不要になったので、delete が不要になったので、削除してください。PlayerServerの2番目のプロパティを変更し、名前付きプロパティrouter http.ServeMuxを削除して、http.Handlerに置き換えました。 これは 埋め込み（embedding） と呼ばれます。Go は典型的な型駆動型のサブクラス化の概念を提供しませんが、構造体やインターフェイス内に型を埋め込むことで、実装の一部を「借用」する機能があります。
PlayerServerが http.Handlerが持つすべてのメソッドを持っているということです。これは単なる ServeHTTPです。http.Handlerを「埋める」ために、NewPlayerServerで作成したrouterに割り当てます。これはhttp.ServeMuxがServeHTTPというメソッドを持っているからです。ServeHTTPメソッドを削除できます。http.Handler)を公開したい interface だけを埋め込んだので問題ありません。http.ServeMuxではなく具象型でも機能しますが、Handle(path、handler)が原因で、PlayerServerのユーザーはサーバーに新しいルートを追加できます公開する。/leagueエンドポイントの開始を設定できます。ここで、いくつかの有用な情報を返すようにする必要があります。Playerの配列が必要なようですので、これをキャプチャする新しいタイプを作成しました。encoding/jsonパッケージからDecoderを作成し、そのDecodeメソッドを呼び出します。Decoderを作成するには、読み取るためのio.Readerが必要です。この場合は、応答スパイのBodyです。Decodeは、デコードしようとしているもののアドレスを受け取ります。そのため、前の行でPlayerの空のスライスを宣言します。Decodeがerrorを返す可能性があります。それが失敗した場合にテストを続行する意味はないので、エラーを確認し、エラーが発生した場合は t.Fatalfでテストを停止します。テストを実行している誰かが解析できない文字列を確認することが重要であるため、エラーとともに応答本文を表示することに注意してください。Encoderを作成するには、http.ResponseWriterが実装するio.Writerが必要です。Decoderを作成するには、レスポンススパイのBodyフィールドが実装するio.Readerが必要です。io.Writerを使用しました。これは、標準ライブラリでの普及と、多くのライブラリが簡単に動作することを示すもう1つのデモです。leagueTableを取得することの間に懸念の分離を導入すると、すぐにはハードコードしないことになるので便利です。Leagueテーブルにストアでスタブするプレーヤーが含まれていることをアサートできます。Leagueを保存できるように、StubPlayerStoreを更新します。これは、Playerのスライスにすぎません。そこに期待されるデータを保存します。Leagueプロパティに一部のプレーヤーを配置して現在のテストを更新し、サーバーから返されることを評価します。StubPlayerStoreに新しいフィールドがあるので、他のテストを更新する必要があります。他のテストではnilに設定します。StubPlayerStoreにあることを知っており、それをインターフェイス PlayerStoreに抽象化しました。PlayerStoreで私たちを渡す誰もがリーグのデータを提供できるように、これを更新する必要があります。getLeagueTable()を削除してから、leagueHandlerを更新してGetLeague()を呼び出します。InMemoryPlayerStoreとStubPlayerStoreには、インターフェイスに追加した新しいメソッドがないため、コンパイラーは不平を言っています。StubPlayerStoreの場合は非常に簡単です。先ほど追加したleagueフィールドを返すだけです。InMemoryStoreの実装方法について説明します。GetLeagueを「適切に」実装することは、マップを反復することでかなり簡単ですが、テストをパスするための最小限のコードを記述しようとしていることを思い出してください。InMemoryStoreでの実装が不完全であるという不快な気持ちに耐えてみましょう。JSONを返していることをマシンが認識できるように、応答でcontent-typeヘッダーを返すことを確認することです。leagueHandlerを更新しますapplication/json の定数を作成し、それを leagueHandler で使用します。assertContentTypeのヘルパーを追加しますPlayerServerを整理したので、InMemoryPlayerStoreに目を向けることができます。これを製品の所有者にデモしようとした場合、/leagueは機能しないためです。/leagueから正しい応答が返されることを確認できます。t.Runを使用してこのテストを少し分解し、サーバーテストのヘルパーを再利用できます。これもリファクタリングテストの重要性を示しています。GetLeague()を呼び出すと、InMemoryPlayerStoreはnilを返すため、修正する必要があります。Playerに変換することだけです。http.Handlerインターフェースを完全に取り入れており、Handlerにルートを割り当て、ルータ自身もHandlerになります。しかし、パス変数のような、あなたが期待するような機能はありません。この情報を自分で簡単に解析することはできますが、それが面倒になったら他のルーティングライブラリを見ることを検討したほうがいいかもしれません。人気のあるもののほとんどは、http.Handlerも実装するという標準ライブラリの哲学に固執しています。