はてなブックマーク

今回は、ひとつのアプリに自動更新購読型と消耗型を共存させたときのサーバーサイドで行うレシート検証のTipsを紹介します。 自動更新購読型課金のサーバーサイド実装について 自動更新購読型課金単体で実装する場合はこちらの記事が参考になります。 (昔書いた記事で古い情報がある場合があります) 下記の記事では月額課金と呼んでいますが、自動更新購読と同義です。 消耗型課金のサーバーサイド実装について 消耗型課金単体で実装する場合はこちらの記事が参考になります。 自動更新購読型課金と消耗型課金を共存させるときのレシート検証 「レシート検証って何？」という疑問については、上記にリンクを載せた記事にすでに書いてあるので、この記事では触れないことにします。 自動更新購読型課金と消耗型課金を同じアプリに共存させようとした場合、気になるのがレシート検証の仕方です。 AppStoreのサーバーから返ってくるレシー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? APNs（Apple Push Notificationサービス）がHTTP/2に対応したのは2年ほど前でしょうか。それまでは、socket通信を直に使って送信する方式だったので、待望の変更だったと思います。 また、去年からAPNsの接続認証に「プロバイダー認証トークン」が使えるようになりました。従来の証明書形式のものは年に1回更新しなければならなかったため、更新を忘れると事故になってしまいます。一方、トークン認証は一度発行したら更新する必要がないだけでなく、トークンを発行したデベロッパーアカウントに紐付いている別のアプリへの再利用も可

注意 この情報は2017年8月25日現在のものです。 目次 消耗型課金全体の処理フロー レシート検証について 課金アイテムの扱い方について 消耗型課金全体の処理フロー 消耗型課金とは、AppStoreで登録できる使い切りのアイテムへの課金のことをいいます。 たとえば、ゲームアプリでライフを購入するときなどは使い切りのアイテムなので消耗型課金になります。一方、1か月など決まった期間サービスが受けられる課金のことを月額課金や、自動更新購読といいます。 (実際のアイテム登録画面) アプリで消耗型課金商品を購入してからの処理の順番は、下記の図のようになります。 アプリからAppStoreへ購入リクエスト AppStoreからレシートを受取る サーバーサイドへBase64エンコード済みのレシートを投げる サーバーサイドはBase64エンコード済みのレシートを使ってAppStoreにレシート問い合わせ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさんは、開発初期の段階でWeb API(以下API)の実装が追いつかずクライアント側が開発できないという経験をしたことはありますか？ クライアント側はAPIがないと開発が滞ってしまうことがありますが、かといってAPIの開発も始まったばかりではすぐに必要なAPIを提供することができません。その問題を解決し、両者でスムーズに開発をすすめるために有効な方法の1つに、APIモックの作成があります。 弊社では、開発初期の段階でSwaggerとその周辺ツールを使ってWeb APIのモックを作成し、スムーズに開発できるようにしています。 Swag

大規模なサービスのAPIを開発する際に、ルールを決めずに開発していると無秩序なコードが散見される運用がしづらいAPIになってしまいます。また、ルールを決めたとしても共有が上手くいかないなどの理由で守られなくなってしまうこともあると思います。 本記事では、APIを運用しやすくするために、ただルールを決定しただけではなく、ルールを守るためにそれぞれ仕組み化をしたことを紹介します。 APIのレスポンスを統一する デコレーターを使ってレスポンスの定義を綺麗に書く パラメーターを統一する Validatorによりパラメーターの明記を強制する コーディング規約を守る LinterとSideCIを導入して修正とレビューの自動化 Linterのルールを適度に調節する 1. APIのレスポンスを統一する ここで言うAPIのレスポンスを統一するというのは、返すAPIフォーマットのブレをなくすことです。フォーマ

下記のように自前でautoload_pathsに追加したパスはproduction環境では自動読み込みされません。 # ./config/application.rb config.autoload_paths += %W(#{config.root}/lib)

最近、iOSのレシート検証をクライアントのみでの検証からサーバーサイドでの検証に実装を変更する機会があったので、その理由や方法、考慮するべき点などを書きました。参考になれば幸いです！ 注意 この情報は2016年8月3日現在のものです。 レシート検証とは？ iOSで月額課金をすると、課金の証明としてAppStoreがレシートを発行します。レシートと言ってもAppStoreが紙のレシートを送りつけてくるわけではなく、電子的な購入情報のことをレシートと呼びます。ユーザーが解約処理をしない限りAppStore側でレシートが自動更新される仕組みになっています。(月額課金の場合) その際に、AppStoreのサーバーにHTTPのPOSTリクエストでレシートを問い合わせ、現在の課金状況を知ることができます。このお問い合わせ処理と、レシートが不正なレシートでないかをチェックする処理を合わせてレシート検証と

1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください！ Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ