まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

以前からなんとなくこの挙動に気付いてはいたのですが、データを受け取る側で加工することで回避できていたので真剣に原因や対処を考えていませんでした。今回とある機能をライブラリ化することになり、「受け取る側ではなく、送る側で対処が必要」になったので真面目に調査して、対処法含めて分かったのでブログに残しておくことにしました。

現象はこのブログエントリのタイトル通りなのですが、まず「何をするとどうなるか」を紹介します。例えば jQuery を使ったこんな内容のコードを実行したとします:
$.ajax({
  url: '/api/item',
  type: 'POST',
  data: { name: 'シャンプー', price: 1000 },
  success: function( result ){
    :
  },
  error: function( err, text, message ){
    :
  }
});

Ajax を使って /api/item に POST リクエストを実行する、という内容です。その際に { name: 'シャンプー', price: 1000 } という JSON データを送信しています。

これを以下のような Node.js のコードで受け取った場合を想定してみます(Node.js はあくまでコードの例であって、Node.js じゃなくても同じ現象が起こります):
var express = require( 'express' ),
    bodyParser = require( 'body-parser' ),
    app = express();

app.use( bodyParser.urlencoded( { extended: true } );
app.use( bodyParser.json() );

  :

app.post( '/api/item', function( req, res ){
  var data = req.body;
  console.log( data );

    :
});



Node.js ではよく使う方法ですが、Express (と body-parser)を使って "/api/item" に POST されたデータを受け取っています("var data = req.body;")。この例では受け取った内容をそのままコンソールに表示しています("console.log( data );")。

先ほどの POST データであれば、コンソール画面には
{ name: "シャンプー", price: 1000 }

という JSON データが表示されるような気がしますが、実際には
{ name: "シャンプー", price: "1000" }

という、price の値が送信した時の数値ではなく、文字列に変換されて送信されます。これが本ブログエントリのタイトルにも書いた『jQuery の $.ajax で JSON データを POST すると整数が文字列になる??』という現象です。

送る側だけでなく、受け取る側も自分達が実装しているのであれば受け取った JSON データの price の値を数値に変換するという手もあります:
//. data.price が文字列だった場合は数値に変換する
if( typeof data.price == 'string' ){
  data.price = parseInt( data.price ); 
}

最悪、この方法で対処できるかもしれませんが、受け取る側を変更できないという前提にした場合、この方法は使えなくなります。つまり「正しいフォーマットで送信する」必要がでてきます。

で、いろいろ調べた結果として、jQuery の Ajax 実行部を以下のように変更することで JSON データ内のフォーマットを壊さずに、JSON データのまま送信することができるようでした:
$.ajax({
  url: '/api/item',
  type: 'POST',
  contentType: 'application/json',
  dataType: 'json',
  data: JSON.stringify( { name: 'シャンプー', price: 1000 } ),
  success: function( result ){
    :
  },
  error: function( err, text, message ){
    :
  }
});

先ほどの例と違う部分を赤字にしていますが、要するに、
  • contentType: 'application/json' を追加する
  • dataType: 'json' を追加する
  • 送信する JSON データ全体を JSON.stringify() で文字列化する
という3つの変更を加えることでそのままのフォーマットで(受信側でも price は文字列の '1000' ではなく、整数の 1000 として)送信することができるようでした。


そういえば以前はこのスタイルで送っていたような気がしつつ、よりシンプルな方法でも(データ型が乱れるだけで)送れることに気付いて、それから省略形で送ってしまっていたような気がします。その結果、データのフォーマットがおかしくなっていた(が、あまり気にしなかった)ということだと思っています。 ともあれ、これで受け取る側を変更しなくても、正しいデータフォーマットのままで送信することができそうです。

jQuery の場合「正確に記述しなくてもある程度できちゃう」から、正確でなかった今までの方法が正しいと勘違いしていたようです。で、足りない部分もちゃんと記述すればできる、と。いい勉強になりました。



久しぶりにウェブサービスを作ってみたので、紹介含めてブログにまとめました。アイデアそのものは2週間ほど前に思いついて脳内設計し、1週間くらい前から作ったり改良を加えたりして、この三連休でとりあえず公開できるレベルになったかな、という感じです。

作ったのはいわゆる CMS (=Contents Management System「コンテンツ管理システム」)です。特徴的な要素として GitHub Issues を使っている、という点が挙げられると思っています。要は CMS のコンテンツそのものは専用 DB などに格納するのではなく、GitHub のリポジトリ内のプロジェクト/課題管理ツールである GitHub Issues を使っています。多くのケースでは GitHub Issues はプロジェクトの課題を記録したり、課題をカテゴリーに分類したり、課題の担当者や解決目標時期を割り当てたり、スレッド形式のコメントを追加したりしながら、プロジェクト全体の進捗を管理することに使われることが多いと思いっています。一方で、この GitHub Issues の仕組み自体はプロジェクト管理だけに使うのはもったいないほど色んな機能が無料で提供されているとも考えることができます。今回作成した GHaC(GitHub as CMS)は GitHub API を使って GitHub のログインや GitHub Issues の取得を行い、CMS 寄りの UI で表示することで CMS として使ってみたら面白いのでは? という興味から生まれたものです。

なお、2022/10/10 の現時点では PC 向けの UI のみ提供しています。


【GHaC の使い方】
GHaC を使う場合はまずウェブブラウザで以下にアクセスします:
  https://ghac.me/

2022101001


GHaC の紹介と簡単な使い方が説明されています。以下、このページに書かれた内容と重複する箇所がありますが、こちらでも使い方を説明します。

GHaC は GitHub のリポジトリを参照して(そのリポジトリの Issues や Comments を取り出して)コンテンツを表示します。例えばサンプルとして dotnsf/sample-issues という公開リポジトリを見る場合を想定します。なお、このリポジトリはソースコードとしては何もコミットされていないので、リポジトリを直接参照すると初期状態のまま表示されます:

https://github.com/dotnsf/sample-issues の画面)
2022101002


ソースコードは空ですが、GitHub Issues としての情報はいくつかの Issues と、各 Issue にコメントがついていたり、いなかったりします:

https://github.com/dotnsf/sample-issues/issues の画面。4つの Open な Issues と、表示されていない1つの Closed Issue が登録されています。また Comments が付与されている Issues は右側に吹き出しマークと一緒に Comments の数が表示されています)
2022101003


GHaC でこのリポジトリを参照する場合は https://ghac.me/ に続けて対象リポジトリを追加した URL にアクセスします。このリポジトリ(dotnsf/sample-issues)の場合であれば https://ghac.me/dotnsf/sample-issues にアクセスします。以下のような画面になります:
2022101004


最初は認証されていない状態でアクセスすることになるので上記のようなログインを促すメッセージだけが表示されています。画面右上の「ログイン」ボタンで GitHub の OAuth 認証ページに移動し、GitHub アカウントを指定してログインします。初回のみ以下のような画面になるので右下緑の "Authorize dotnsf" ボタンをクリックしてください:
2022101005


ログインが成功すると以下のような画面に切り替わります。なお、このリポジトリの例(dotnsf/sample-issues)は公開リポジトリなので誰がログインしてもこのように表示されますが、非公開リポジトリの場合はログインしたユーザーの参照権限の可否によって表示されたり、されなかったりします:
2022101006


画面最上部右にはログインしたユーザーの(GitHub の)プロフィールアイコンが表示されます。このアイコンをクリックすると GitHub からログアウトして GHaC のトップページに戻ります。またその右には GitHub API を実行できる回数※の目安が円グラフで表示されています。このグラフ部分にマウスのカーソルを重ねると、リセットまでの残り API 実行回数と、次回リセットの日付時刻が表示されます:
2022101007



GitHub API は1時間で 5000 回実行できます。1つのリポジトリの Issues や Comments を取得するために実行する API の回数はリポジトリによって異なります。↑の例ではこのページを表示するために既に4回実行していて、2022/10/10 19:50:06 までにあと 4996 回実行できる、という内容が表示されています(2022/10/10 19:50:06 になると API 実行はリセットされて、新たに 5000 回利用できるようになります)。

また画面上部には指定したリポジトリ内の open な issues がテーブル形式で表示されています:
2022101008

(参考 もとのリポジトリの Issues の同じ該当部分)
2022101003


画面下部には各 Issues と、その Issue に Comments がついている場合は全ての Comments がスレッド形式で表示されています。画面をスクロールすれば全て見ることができますが、特定の Issue の内容を確認したい場合は上部テーブルの該当 Issue をクリックすると、その Issue のスレッドに移動します。

例えば「ラベル付き issue」(Comments 数は2)と書かれたこの部分をクリックすると、
2022101008


該当 Issue が表示されている箇所までスクロールして表示することができます:
2022101009


Issue 本文や Comments 内容はマークダウン記法で記述されており、GHaC でも同様に表示されます(mermaid 記法には対応していません)。マークダウンによるリッチテキストを含む Issues や Comments はリッチテキストが再現されて表示されます:
2022101010

(2022/10/13 追記)
mermaid 記法と MathJax 記法に対応しました。


また現時点では GHaC は参照専用のツールです。GitHub リポジトリ内の Issues や Comments を編集するにはこのリポジトリを編集する権限をもったユーザーでログインした後に、画面内の GitHub アイコン(オクトキャットアイコン)をクリックすると・・
2022101009


対象リポジトリの対象 Issue の GitHub 画面が別タブで表示されます。必要に応じて、この画面から Edit ボタンをクリックして内容を編集したり、Comments を追加したり、New issue ボタンから新しい Issue を追加してください(保存後に GHaC 画面をリロードすればすぐに反映されているはずです)。余談ですが GitHub Issues の編集画面はマークダウンで記述できるだけでなく、OS からのコピー&ペーストで画像を貼りつけることができるので、リッチテキストの編集がとても楽です:
2022101011


なお、GHaC はデフォルトでは指定されたリポジトリの Open な Issues だけを対象にこのような画面を提供します。全ての Issues やクローズされた Issues だけを対象としたい場合は URL の最後にそれぞれ state=all (全ての Issues)や state=close (クローズされた Issues)というパラメータを付けてアクセスすることで目的の Issues を変更することができます(実はこれ以外にも URL パラメータで対象 Issues を絞り込むことができるようにしていますが、GitHub API でのオプションと同じ仕様にしているので興味ある人は自分で調べてみてください):
2022101012

2022101013


【まとめ】
このように GitHub Issues をウェブコンテンツのように使うことができるようになるのが GHaC の魅力です。GitHub Issues 本来の使い方とは異なるので少し慣れが必要かもしれませんが、ある意味で GitHub を無料のデータ管理ができるヘッドレス CMS のように使うことができると思っています。

なおこの GHaC を使うことで、公開されている全ての GitHub リポジトリを対象にこのような UI で Issues や Comments を表示することができるようになります。ただ例えば node-red/node-red のような Issues が多く登録されているようなリポジトリに対して実行すると1回の表示に必要な API 実行回数も多くなり、結果として表示されるまでにかかる時間も長くなってしまいます。その点に注意の上でリポジトリを指定して実行してください:
2022101014


(表示まで1分近くかかりました・・)
2022101015


まだまだ不具合も見つかっており、今後はその対処が必要になることに加え、現在は Oracle Cloud の無料インスタンス1つを使って運用していることもあって決して潤沢なサーバー環境ではありません。いろいろ不便があるかもしれませんが、ある程度理解した上で(主に情報提供用の)コンテンツ公開サービスと考えると、アクセス権管理も含めて結構使い道あるサービスなのではないかと思っています。


しばらく今の形で公開するつもりなので是非いろいろ使っていただき、ご意見やご要望などあれば伺って今後のサービス向上に役立てていきたいと思っています。


LINE PayAPI は(クレジットカード情報を取り扱う必要がない、という点で)個人プログラマーレベルでもモバイルやウェブで決済アプリを作ることができて便利です。

また LINE Pay API には「サンドボックス」と呼ばれる開発者向け機能が提供されており、このサンドボックス機能を使うことで「実際には決済しないが、実際の決済と同じ挙動を示す課金アプリケーション」を開発・動作確認することができます。アプリケーション開発段階での動作確認やテスト時に決済料金が発生しないので、安心して使うことができます。

一方で、そのようにして作ったアプリを本当に決済する場合は、サンドボックスの ID ではなく、LINE Pay に加盟店登録した ID を使ってアプリを運用する必要があります。この加盟店登録、個人でも(個人事業主でも)運転免許証などの身分証明があれば行うことができるようでした。自分は LINE Pay API を使った課金アプリ開発に興味があるのですが、実際に加盟店として登録する際の手順や手間なども知っておきたかったので、試しに加盟店登録してみました。以下、その手順の(2022/09/07 時点の内容での)紹介です。


【事前準備】
運転免許証や保険証があればOKです。表面と裏面両方の写真を撮っておきましょう(後ほど使います)。

加えて LINE のアカウントと、LINE がインストールされたスマホがあると理想です。これは加盟店として必要というよりも、アプリケーションの動作確認時に必要になります。


【申請手順】
最初に以下の URL をウェブブラウザで開き、加盟店申請を始めます:
https://pay.line.me/merchant-apply/jp/selection/login-v2

以下のような画面が表示されたら、画面を下にスクロールします:
2022090701


「申請に必要な書類」という項目があります。今回は個人事業主として申請するので、「個人事業主の場合」を選択して内容を確認し、同時に必要な書類(身分証明書を撮影した画像ファイル)を用意します:
2022090702


更に下にスクロールすると加盟店登録を開始するボタンが現れます。メールか LINE で登録できるようですが、(実は私自身はあまり LINE を使わないこともあって(苦笑))今回は「メールで加盟店登録を始める」を選択しました:
2022090703


というわけで、以下はメールでの登録手順となります。最初にメールアドレスを登録します。この後、このアドレスにメールが送信されるので、受け取ることができるアドレスを入力します。そして個人情報取り扱いにチェックを入れて、「認証メールを送信」ボタンをクリックします:
2022090704


すると指定したアドレスに以下のようなメールが届きます:
2022090705


この画面を下にスクロールすると「LINE Pay 加盟店に登録する」ボタンがあるので、これをクリックします:
2022090706


ここから実際に登録する加盟店の情報を入力していきます。まず LINE Pay 加盟店ダッシュボードにアクセスするための加盟店 ID (となる文字列)※1を入力し、右の重複確認を押します。IDの下に「使用可能」と表示されれば、その ID を使うことができます。その後、この ID のパスワードを入力し、再度メールアドレスを入力して、「申請を続ける」ボタンをクリックします:
2022090707

※1 実際の加盟店IDは (入力した文字列)@line.pay となります


アカウント画面が表示され、確定した加盟店 ID が画面に表示されます。続けて「加盟店申請を行う」ボタンをクリックします:
2022090708


ここから加盟店としての登録が始まります。まず加盟店申請の最初に「法人」か「個人」かを選択します。今回は個人登録なので、個人の側にある「選択する」ボタンをクリックします:
2022090709


次に決済手段を選択します。今回自分は自分で開発するウェブアプリ上でのオンライン決済を行うための申請なので、オンライン決済側の下にある「選択する」ボタンをクリックします:
2022090710


以下のような警告メッセージが表示されますが、(他の選択肢もないので)そのまま「オンライン決済のお申込みを続ける」ボタンをクリックします:
2022090711


オンライン決済サービスの利用料金が表示されます(これによるとデジタルコンテンツの決済手数料は 5.5% らしいです、ふむふむ)。内容を確認したら「次へ」ボタンをクリックします:
2022090712


利用規約がいくつか表示されます。内容を参照し、同意する場合はチェックしてください:
2022090713


画面下までスクロールし、すべての項目にチェックが入り、また販売方法や確認事項が「該当しない」が選択されていれば「次へ」ボタンをクリックしてください:
2022090714


次に加盟店の業種情報を入力します。業種カテゴリーとして選択肢が用意されているので、大分類と小分類で近いものをそれぞれ選択します。このまま下にスクロールします:
2022090715


画面下部で取引商材を記入する欄があります。ここにはフリーテキストで商材となるものを入力します。最後に「次へ」ボタンをクリックします:
2022090716


そして会社(個人事業主)に関する情報を入力します。個人事業主の場合、ここは個人名や個人住所を入力することになります。名称や住所、電話番号が入力できたら「次へ」をクリックします:
2022090717


会社・個人事業者の情報として、メールアドレスと店舗またはサイトの URL を指定します(ここ、僕はまだ完成していないサイトなので、アクセスしても認証を求められるだけのアドレスを指定したのですが、審査大丈夫かな・・・)。最後に「次へ」ボタンをクリックします:
2022090718


次は会社・個人事業主の代表者の情報を入力します。個人事業主の場合は先ほどと同じ情報を入力することになると思います。また代表者自宅住所が「会社住所と同一」である場合は、ここにチェックを入れます:
2022090719


次に精算金の振込銀行口座を指定します。金融機関名、支店名、口座種類、口座番号、口座名義を入力します:
2022090720


下にスクロールすると、本人確認書類の添付欄があります。ここに先ほど用意した書類(下の例では運転免許証をカメラで撮影した画像)を添付しています。
2022090721


申請の最後に最終確認ページが表示されます。これまでに入力してきた内容が表示されるので、内容あが正しいことを確認します:
2022090722


下までスクロールし、問題がなければ「提出」ボタンをクリックします:
2022090723


これで LINE Pay 加盟店申請が完了・・・したと思います:
2022090724


同時に登録メールアドレスに以下のようなメールが届きます。申請は完了したので、審査待ちという状況に変わります。ひたすらじっと待ちます:
2022090725


・・・で、今は申請結果を待っている状態です。


個人事業主で申請すると自分の名前を何度か入力する必要があって少し面倒にも感じますが、終わってみるとさほどややこしい内容でもなく、これで登録完了するならかなり簡易化されているように思いました。

まだ申請の結果はわかっていないのですが、手続きという意味では一通り紹介できていると思うので、この段階でいったん公開とします。なお、ここで申請した加盟店登録が通った先では、このサンプルアプリを応用したウェブアプリケーションで使う予定です:
http://dotnsf.blog.jp/archives/1080925187.html




【2022/09/07 追記】
申請時に記載した「店舗サイトの URL」に不備があったようで、個別メールで連絡が来てました。私が記載した URL はアカウント ID とパスワードがないと先に進めないものだったのですが「それだと内容が確認できない」とのこと。ん-、でもアカウントを持ってないと入れない仕様を変えたくはないんだよな。。

という事情も含めて返答してみました。さてどうなることやら。


【2022/09/09 追記】
(アプリケーションがまだ開発中だったという背景もあるのですが)私が申請したアプリケーション URL では商品の内容確認ができなかった、との返答が再度ありました。ん-、まあとはいえアプリができる前に認証外したくはないんだよな。。

というわけで、まだ URL が存在していない場合店舗向けに別途提供されている「販売事業者名と取り扱い商材の確認」をするためのエクセルフォームを送付いただき、ファイルに記入して申請する形で再度申請してみました。今度は「この内容で審査を継続する」との返答まではいただいています。

さて申請結果はどうなることか・・・


【2022/09/12 追記】
無事審査を通過できたようです。サービスの URL がまだ開発中であるか、サービスそのものを非公開(会員でないと中が見れない)ようにする場合は、上述のエクセルフォームを使った申請を使った方がよさそうです:
20220912




このページのトップヘ