ウェブ
webhook.siteを通じてWebhookをテストする
Webhookとは？ 一般的にリクエストはクライアントからサーバーに送信され、サーバーはクライアントに応答を返す構造になっています。（リクエスト-レスポンス構造） 通常、非定期的に発生するユーザーの行動を知らせる目的で使用され、例えば、通知サーバーと会員サーバーが分離されたMSA構造の場合、ユーザーがウェブサイトに登録をすると、登録を知らせるメールを送るようなケースです。 graph TD; ユーザー -->|登録| 会員サーバー; 会員サーバー -->|登録Webhook| メールサーバー;実際には非常に大きな機能ではなく、一般的なリクエストと大差ありません。サーバーで特定のイベントが発生した時に、特定のサーバーやクライアントにリクエストを送信することを知っていれば大丈夫です。 Webhookのテスト では、Webhookはどのようにテストできるでしょうか？ 1. 完成を待つ 例えば、会員サーバーとメールサーバーがある場合、すべて実装して登録を試みることで簡単にできるかもしれません。しかし、欠点は、チームメンバーが複数いる場合、各自がサーバーの機能を実装すると、Webhookのテストのためにすべての機能の実装を待たなければならない点です。 2. ダミーサーバーを実装する また、ダミーサーバーを自分で実装する方法もあります。 結局、リクエストを受けることが目的なので、特定のエンドポイント（メールサーバーを仮定）を持つサーバーを作成し、会員登録に成功した時にリクエストを送信すればよいのです。 例えば、このような感じになります。 package main import ( "fmt" "net/http" ) func main () { http.HandleFunc("/webhook", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Webhook received!") }) http.ListenAndServe("8080", nil) } このようにサーバーを実装し、会員登録時に/webhookにリクエストを送ればよいのです。
2025年4月8日
APIサーバーの観点からイベント駆動アーキテクチャ(Event Driven Architecture)を学ぼう
たまに開発をしていると、APIの応答が遅い時があります。このような場合、APIの応答を速くするためにコードを最適化したり、キャッシュを適用するなどの方法を使用することができます。 もちろんこれらの方法が可能であれば良い方法であり、最善ですが、時にはどうしても時間がかかる作業があります。 AWSを例にしてみましょう。特定のAPIがあり、EC2マシンを立ち上げるAPIがあると仮定します。この時、EC2マシンを立ち上げるAPIはかなり時間がかかる作業です。しかし、コードの最適化だけでこの時間を短縮できるでしょうか？ コンピュータをオン・オフする作業はどんなに最適化しても、かなり時間がかかるでしょう。（筆者のコンピュータも起動するのに30秒は軽くかかります） これを同期APIで処理するならば、次のように構成できるでしょう。 Go言語を通じて一度見てみましょう。 package main import "net/http" func StartEc2Handler(w http.ResponseWriter, r *http.Request) { // ... // EC2マシンを立ち上げるコード // ... w.Write([]byte(`{"result": "success"}`)) // JSON形式で応答 } 単純に層間の区分なしにコードが書かれています。実際のコードではservice、repositoryなどさまざまな階層があるでしょう。 上の図の例では便宜上、極端にユーザー -> サーバ間の通信に1秒かかると仮定しています。（実際にはミリ秒単位でずっと短いです。） 図で見られるように、APIリクエストを受けてEC2マシンを立ち上げる作業を処理し、その結果を返す方式です。 同期方式ではリクエストを受けたとき、そのリクエストを処理するまで応答しないため、ページを離れたり、リフレッシュしたりする作業を行うと作業が途中で中断されます。 ユーザーの立場では次のようなローディング画面を32秒間見なければならないことになります。 これほど恐ろしいことはないでしょう。 途中で切れるのを防ぐために次のように警告が出るように処理する場合もあります。しかし、ユーザーが確認を押すことを防ぐことはできません。
2025年1月24日
REST? RESTful? REST API? って何なの？
こんにちは！今回の投稿では、ウェブで広く使われているRESTについて調べてみたいと思います。 RESTはロイ・フィルディング（Roy Fielding）という人が2000年に博士論文で紹介したものです。 RESTはRepresentation State Transferの略で、ハイパーメディアシステムのためのソフトウェアアーキテクチャの一形式です。 ハイパーメディア（Hyper Media）とは？知らない単語が出てきましたね？ ハイパーメディアとは何でしょうか？ ハイパーメディアとは、テキスト、図形、アニメーション、ビデオ画像など複数の情報をノードとリンクで有機的につなげたネットワークの網構造を指します。 リンク機能を利用して情報を有機的に結び付け、順次引き出す方式で関連情報を対話的に引き出せることが特徴です！情報がリンクを通じて接続されていることが核心です！ それでRESTって何？RESTは資源(Resource)を資源の名前（資源の表現：Representation）で区別して資源の状態（State）を送受信するすべてを意味します。 こう言うと非常に難しいですよね？もう少し簡単に表現してみます。 資源とは、私たちが普段インターネットサーフィンをしながら見るものです。テキスト、動画、画像などサービスが提供するすべてを資源と表現できます。 資源の表現とは何でしょうか？資源に名前を付けたものと見なせます。 インターネットであるデータを見るためには名前を付ける必要があります。 次のような情報を表現したいときのことを考えてみましょう。 これはライオンの画像です。でもネットワークがどうやってDBにあるライオン画像を出力できるのでしょうか？ 次の図のように、ライオン画像をインターネットブラウザが資源の名前を通じて呼び出します。 写真から見た通り、正確には資源を含むリンクを通じてその資源を要求することになります。 このように資源の名前を明示し、その名前を通じて資源を送受信することを資源の表現と呼ぶのです :) しかしインターネットで行われる作業は、ライオンの画像を得る（GET）作業だけではないでしょう？ RESTメソッドRESTはHTTPプロトコルを通じて複数の要求を処理できるように、主に4つのメソッドを提供します。 GET: 情報を取得することに重点を置いたプロトコルです。皆さんがNAVERにログインするとプロファイルに自身の情報が表示されますよね？NAVERはログインしてメインページをロードする過程でユーザーのプロファイル情報を要求（Request）し、サービスはその情報を返します。 POST: 情報を生成することに重点を置いたプロトコルです。もし皆さんが会員登録をすると、ウェブブラウザに記録されたユーザー情報がDBに反映されるためにPOSTメソッドを通じてサービスに伝達されます。 PUT: 情報を修正することに重点を置いたプロトコルです。NAVERでプロファイルを修正すると、このプロトコルを通じて修正された情報をサービスに伝達します。 DELETE: 情報を削除することに重点を置いたプロトコルです。会員脱退、投稿削除などDBのレコードを削除するためにサービスに要求する際に使用します。 それでは実際のデータはどうやって送受信するの？（資源の状態：State）RESTの概念において、核心は資源を送受信する方式にあります。 実際のデータはXMLやJSONフォーマットを通じてファイルを送受信するのですが、例えば先ほどのライオン写真はこのようにJSONで表現することができます。 { "pic_name": "lion", "link": "https://cdn.example.com/img/lion.png" } ▲ 例のJSON
2022年2月28日
MVCについて知ろう
MVCはModel、View、Controllerの略です。ウェブアプリケーションを構成する様々な方法論の一つで、コンポーネントを3つに分けた代表的なパターンです。有名なウェブフレームワークであるSpring Frameworkで使用されていることで知られており、細かい違いはありますが、様々なウェブフレームワークが似たパターンを採用しています。 他のフレームワークには何があるの? 似たパターンとしてはMVTパターンがあります。PythonベースのフレームワークDjangoで使用される構成パターンで、Model、View、Templateの略です。各役割はMVCパターンとほぼ一致しますが、マッチングの基準が異なります。 MVCとMVTの違い 上の図を見れば、MVCとMVTの関係がどのように異なるかがわかります。 DjangoのViewはSpringではControllerであることがわかりますね！ さらにSpringでのViewがDjangoではTemplateであることもわかります。 まあ、ここまでで違いも分かったことですし、そろそろMVCが何かを見てみましょうか？ Model, View, Controller そして User Model, View, Controllerの関係を簡単に表現すると上の画像のようになりますが、実際には矢印がさらに色々な方向に伸びることができます。 ここで重要なのは矢印の方向ではなく、流れを見ていただきたいのです。 Model まずはModelを見てみましょう。Modelはデータを保持するオブジェクト、エンティティを指す言葉で、データベースに保存する実際のデータのクラスが含まれるオブジェクトです。 簡単に言えば、データベースと通信する友達と考えれば良いでしょう。 CRUD操作が行われるすべてのオブジェクトの情報を保持していなければならず、View、Controllerについて参照してはいけません。 View ユーザーに表示されるUIを保持するオブジェクトです。RestFulなAPIが主流となり、近年ではSpringで直接HTMLを保持することは少なくなりました。Vue.js、ReactといったフロントエンドフレームワークがSpring MVCのViewを担当していると考えるべきでしょう！ ユーザーから最初に入力を受け取り、Controllerに送る役割を担います。 HTMLのinput、checkbox、submitボタンなどのユーザー入力タグ、データベースから取得したデータをユーザーに表示する部分などを処理します。 Controller ユーザーからのリクエストを受け取り、適切にデータを処理し（Model）、Viewを呼び出す、または非同期通信の場合、状況に応じた形式（JSON/XML..etc）で応答する役割を果たします。 まとめ 今日は簡単にMVCパターンについて学びました。 初めての技術ブログを作成する上で、一つの投稿にどれほどの労力が必要なのかを知ることができました。 次回のトピックでは、Spring MVCパターンについてもう少し詳しく調べてみたいと思います。
2022年2月22日