#処理フロー

ServiceはまずリクエストをsalvoのResponseに変換し、その後ルーティングマッチング段階に入ります。

#ルーティングマッチング段階

ルーティングマッチングは追加順序に従い、外から内へ、上から下へ順にフィルターを実行します。いずれかのフィルターが失敗すると、マッチング失敗と見なされます。

マッチング過程では、リクエストのパス情報が存在します。マッチングが進むにつれ、パスフィルターがマッチングに成功すると、そのマッチしたパス部分が消費されます。全てのパスが消費され、かつマッチングチェーン上でフィルターのマッチング失敗がなく、現在のチェーンの最後のRouterにgoalのHandlerが存在する場合、マッチング成功となり、マッチング段階が終了します。マッチングチェーン上の全てのHandlerを収集し、実行段階に進みます。

パスが消費し尽くされていない状態で、チェーン上のフィルターがエラーを起こさず、かつ続けてマッチング可能な子ルートがなくなった場合、現在のチェーンはマッチング失敗と見なし、次のルートマッチングに進みます。

全てのルートのマッチングが終了し、成功しなかった場合、エラーキャプチャ段階に入ります。

#Handler実行段階

マッチング段階で収集されたHandlerリストに従い、順次Handlerを実行します。実行過程で、前段のミドルウェアはctrl::call_next()を呼び出して後続のミドルウェアを先に実行させ、その後自身のロジックを実行できます。実行過程でステータスコードエラーやリダイレクトが発生した場合、後続のHandlerは実行されません。この時、ステータスコードがエラーかつResponseのBodyが未設定またはResBody::Errorの場合、エラーキャプチャ段階に入ります。そうでない場合はキャプチャ段階をスキップします。

#エラーキャプチャ段階

Catcherはエラー処理を行うための型で、ミドルウェア(hoops)を追加することもできます。エラーはCatcher内の全てのHandlerを順次通過します。あるHandlerがエラーを処理し、後続のHandlerの実行を継続したくない場合、ctrl.skip_rest()を呼び出して後続のHandlerをスキップし、直接キャプチャ段階を終了させることができます。

Catcherはデフォルトで、デフォルトエラー処理として機能する1つのHandlerを含む必要があります。デフォルトはDeaultGoalですが、完全に独自のHandlerをエラー処理のデフォルト実装としてカスタマイズすることも可能です。これはリクエストヘッダーで要求されるcontent-typeに応じて対応する形式のエラーメッセージを表示し、json、xml、text、htmlの4つの表示形式をサポートしています。DeaultGoalはまたいくつかの表示設定を提供しており、例えばデフォルトではhtml形式表示時にsalvo関連リンクを表示しますが、DefaultGoal::footerまたはDefaultGoal::with_footerを呼び出して独自のカスタムフッターに設定することもできます。

ServiceはsalvoのResponseをhyperのResponse型に変換し、最終的にブラウザなどのクライアントに返されます。

#Salvoリクエストライフサイクル

これはSalvo WebフレームワークがHTTPリクエストを処理するライフサイクルの視覚的表現と説明です。