SPIKE REST APIで受注管理をしてみる
背景 Payment Advent Calendar 12月9日分 今日までは、クレジットカードに対して課金を行ったので、行った課金の管理を行います。 概要 REST APIを使って、課金を管理します。 管理するオペレーションは、仮売上の実売上、実売上キャンセル、仮売上キャンセルの3つ。 サンドボックスでテストしてみます。 デモ デモページ https://matsu.teraren.com/spike-api-demo-php/charges/ github ソースコード （SPIKE Checkout, Token APIのデモコードも1つにまとめました） 1ページ目 こんな感じで受注一覧が表示されます。 今回はデモのため、ページングを行っていません。 そろそろModelとViewを分離しないと、コードを書くのが辛くなってきました。 2ページ目 以下のような結果表示が出たら成功です。
SPIKE API (SPIKE Checkout)を使ってみる
概要 SPIKEの特徴 サンドボックス環境はアカウントを作るだけで利用出来ます。 本番環境でSPIKEのAPIを利用するためには月額3,000円のビジネスプレミアムに申し込む必要が有ります。 この記事ではサンドボックス環境でテストしてみます。 SPIKE開発ドキュメント 開発用ドキュメントは、ユーザ登録後に誰でも閲覧でき、Sandbox環境も利用出来ます。 https://spike.cc/dashboard/developer/docs SPIKE Checkout利用時のシーケンス 単発決済の場合のシーケンスを書いてみました。 SPIKE Checkoutを利用しないで、Token APIを利用すれば、自分のサイト上でユーザがクレジットカード情報を入力させることもできます。その場合は、Full APIに申し込む必要が有ります。 シーケンス図は、FastPayの時に書いた物を流用したので
Railsで作ったREST APIをSwagger対応
背景 Web API Advent Calendar 12月3日分@takurosさんの12月2日のSwaggerとは何か？ を前提としています。 概要 swagger-docs を使ってRailsのREST APIをswaggerで表示出来るようにします。郵便番号検索APIのAPIを表現してみます。 手順 Gemfileにswagger-docsを追加します。 しかしながら、masterブランチにバグがあり、pathにスラッシュが付かないので、forkされたgemを使います。 gemをインストールします。 $ bundle swaggerの初期設定ファイルを作成します。 initializerをconfig/initializers/swagger_docs.rbに作成して、以下のようにAPIサーバの基本情報を書いておきます。 該当するControllerに、API仕様を追記します。 今
郵便番号検索 REST API
無料 私自身が業務でWebサービスを構築している際に、無料で手軽に使えて安定しているサービスが欲しいと思っていましたがどれも有料のサービスやユーザ登録が必要だったりして利用が面倒でした。 そこで、誰でも手軽にアクセス数を気にしないで使えるサービスを作りたかったので作りました。 寄付はGithubから 利用規約 アクセス制限無し CloudflareのCDNを利用しているためほとんどのデータはCDNでキャッシュされています。CloudflareのCDNの利用料が無料なのでこのAPIサービスも無料で提供できています。 Cloudflare CDN
銀行くん | 金融機関コード API
無料 私自身が業務でWebサービスを構築している際に、無料で手軽に使えて安定しているサービスが欲しいと思っていましたがどれも有料のサービスやユーザ登録が必要だったりして利用が面倒でした。 そこで、誰でも手軽にアクセス数を気にしないで使えるサービスを作りたかったので作りました。 寄付はGithubから 利用規約 アクセス制限無し CloudflareのCDNを利用しているためほとんどのデータはCDNでキャッシュされています。CloudflareのCDNの利用料が無料なのでこのAPIサービスも無料で提供できています。 Cloudflare CDN
JSON-RPC 2.0のススメ
RESTfulなHTTPリクエストでは、JSONでデータを返すのが一般的ですよね。 そんなJSONのスキーマが各社ばらばらで、統一感が無いけど、何かしらの仕様があるかと思って探したら、ありました。 JSON RPC 2.0 正常系なら、意識しないでデータを直接表現してしまえば良いと思いますが、エラーを表現するときにはある程度仕様に則っておいた方がクライアント・サーバの相互運用性が高まります。 2.0の仕様は2010-03-26に出ているし、1.0から長く運用されているようだし、様々なユースケースをカバーしているので、JSONをやりとりする場合は、使わない手は無いかと思います。 プロトコルの内容は以下のような感じで、すごい大枠だけ決まっているので、2分もあれば理解できるでしょう。 --> {"jsonrpc": "2.0", "method": "foobar", "id": "1"} <-
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
