【ITニュース解説】Build a Product Catalog in YunCMS: From Studio to REST API

この記事は、コンテンツ管理システム（CMS）である「YunCMS」を使って、Webサイトやアプリケーションで表示する「商品カタログ」を構築する具体的な手順について解説している。システムエンジニアを目指す人にとって、データ管理、API（アプリケーション・プログラミング・インターフェース）の利用、そしてセキュリティという、Webサービスの基本的な要素を学ぶ良い機会となるだろう。

まず、商品カタログとは、WebサイトやECサイトで商品情報を一覧表示したり、詳細を表示したりするためのデータの集まりである。これを実現するには、主に三つの要素が必要となる。一つは、商品情報を追加・編集・削除する「管理画面」だ。記事中ではこれを「Studio」と呼んでいる。二つ目は、Webサイトやスマートフォンアプリがその商品情報を読み取るための「API」だ。APIは、プログラム同士がデータをやり取りするための窓口のようなもので、Webサイトが商品のリストを取得したり、詳細情報を表示したりする際に利用される。そして三つ目は、まだ完成していない商品や、社外秘の情報が誤って公開されないようにするための「公開範囲の制御」である。この制御は、データのセキュリティを確保し、ユーザーに見せるべき情報だけを適切に提供するために不可欠だ。この記事では、これら三つの要素をYunCMS上でどのように実現するかを、順を追って説明している。

前提として、この解説はYunCMSがインストールされ、管理者としてStudioにログインできる環境があることを想定している。動作環境としては、Node.js 24とMySQL 8.4が使用されている。具体的な手順は、YunCMSの管理画面（Studio）を使って進められる。

最初のステップは「商品コレクションの作成」である。「コレクション」とは、データベースにおけるテーブルのようなもので、関連するデータをまとめて管理する「データの入れ物」だと考えればよい。ここでは、商品情報を格納するための「Products」という名前のコレクションを作成する。この際、「Products」は人が管理画面で識別しやすい「表示名」として、「products」はAPIを通じてデータを参照する際にプログラムが利用する「APIキー」として設定される。APIキーは一度設定すると、そのコレクションにアクセスするための重要な識別子となるため、安易に変更すべきではない。

次に、「カタログフィールドの定義」を行う。これは、作成したコレクションにどのような種類のデータ項目（フィールド）を含めるかを定義する作業だ。例えば、商品には「商品名（name）」、「SKU（在庫管理単位である製品コード）」、「価格（price）」、「在庫数（stock）」、「ステータス（status）」といった情報が必要になる。これらのフィールドごとに、それがテキストなのか、数値なのか、といった「データ型」を指定し、必須項目かどうかを設定する。特に「ステータス」フィールドは「active」（公開中）と「draft」（下書き）という二つの状態を想定しており、初期値を「draft」に設定しておくことで、未完成の商品が意図せず公開されることを防ぐ第一歩となる。価格のような数値データは、小数点以下の桁数まで正確に管理するため、「precision」（桁数）と「scale」（小数点以下の桁数）を指定することも重要である。

フィールドを定義したら、「商品データの追加」を行う。ここでは、デモンストレーションとして三つの商品（「Canvas Backpack」「Ceramic Mug」「Desk Lamp」）をStudioの管理画面から登録する。このうち「Desk Lamp」は「draft」（下書き）ステータスで登録されており、これが後ほど公開されないことを確認するために使われる。管理者は、登録された全ての情報（商品名、SKU、価格、在庫、ステータス）をStudioで確認できる。

ここまでの作業でデータが準備できたため、次に重要なのが「公開用カタログ読み取り制限の設定」である。これは、Webサイトを訪れる「Public」（匿名）ユーザーが、どの商品情報にアクセスできるか、どのフィールドを見ることができるかを厳密に制御するセキュリティ設定だ。ここでは、「products」コレクションに対する「Read」（読み取り）権限をPublicユーザーに許可するが、全ての情報を公開するわけではない。具体的には、「id」「name」「price」「status」のフィールドのみを公開対象とし、「SKU」や「在庫数」といった管理側の情報は公開しないように設定する。さらに、より重要なのは「ステータスがactive（公開中）のデータのみ」をPublicユーザーに表示するというルールを設定することである。このルールにより、「draft」ステータスの「Desk Lamp」は、たとえデータが存在していても公開APIからは取得できなくなる。また、Publicユーザーにはデータの「作成（Create）」、「更新（Update）」、「削除（Delete）」の権限は与えない。これにより、悪意のある第三者によるデータの改ざんや削除を防ぐことができる。

設定が完了したら、「REST APIによるカタログの読み取り」を通じて、その設定が正しく機能しているかを確認する。ここではcurlコマンドというツールを使って、実際にAPIにリクエストを送信する。APIのURLは、作成したコレクションのAPIキーを使って/items/productsとなる。リクエストには、表示したいフィールド（name, price, status）、ソート順（sort=name）、取得件数（limit=20）といったパラメータを含める。このリクエストは「匿名リクエスト」であり、認証情報を含めない。その結果、返されるデータは、設定した通り「Canvas Backpack」と「Ceramic Mug」という「active」ステータスの二つの商品のみであり、公開を許可していない「SKU」や「在庫数」のフィールドは含まれないことが確認できる。一方、「draft」ステータスの「Desk Lamp」はレスポンスに含まれない。また、価格が500以上の商品のみを抽出するなど、さらに細かな条件でデータを絞り込むことも可能だ。これは、設定された権限の範囲内であれば、APIの利用者が自由にデータをフィルタリングできることを意味する。

最後のステップは「フロントエンドとの接続と境界の確認」である。実際にWebサイトやアプリケーションを構築する際には、JavaScriptなどのプログラムからこのAPIを呼び出して商品情報を取得する。記事ではNode.jsのfetch関数を使ったコード例を示している。もしWebサイトとAPIが異なるサーバーで動作している場合、「CORS」（Cross-Origin Resource Sharing）といった技術的な設定が必要になることもある。ここで最も重要なのは、管理画面で管理者が見るデータと、公開されたAPIを通じて匿名ユーザーが見るデータが、設定した権限によって明確に区別されていることを再確認することだ。記事では、以下のテスト結果が示されている。Publicアクセスを許可する前に読み取りを試みると「403 Forbidden」（アクセス禁止）エラーが返り、許可後は「200 OK」（成功）で二つの商品が返される。また、APIリクエストで存在しない「draft」商品を要求したり、非公開の「SKU」や「在庫数」フィールドを要求すると、それぞれ空のリストや「400 Bad Request」（不正なリクエスト）エラーが返される。匿名ユーザーが商品を作成・削除しようとすると「403 Forbidden」エラーが返されることも確認されている。これらの結果は、設定したセキュリティ境界（アクセス制限）が正しく機能し、データが適切に保護されていることを明確に示している。

この一連の作業を通じて、チームが管理画面でデータを管理し、WebサイトやアプリがAPIを通じてデータを読み取り、かつ未公開の商品や機密情報が外部に漏れないようにするための「境界」を構築するプロセスを学べたはずだ。この基礎を元に、今後は商品画像、カテゴリ分類、複数の管理者ロールの設定、さらにはカート機能や決済連携といった、より複雑なECサイトの機能へと発展させていくことができるだろう。システムエンジニアにとって、このように具体的な手順を通じて、データのモデリング、API設計、そしてセキュリティの基本を実践的に学ぶことは非常に価値がある。