創作文芸見本誌会場HappyReadingに書誌情報APIを実装しました
APIといえるかどうかはともかく。
創作文芸同人誌のプレビュー・立ち読みサイトのHappyReadingの作品ページに掲載されている書誌情報をXMLで提供するようにしました。
『創作文芸見本誌会場HappyReading』https://books.doncha.net/happy-reading/
今さらですが、HappyReadingはけっこうな量の入力項目があります。
にも関わらず登録いただいてるので、入力された情報をHappyReading以外（たとえばサークルや個人のサイト）で使えれば、読者さんへの告知の幅も手軽に広げることができるのではないかということでXML。
平たく言っちゃうと、自分のサイトやブログでも紹介したいのにまた同じことを書くのは面倒くさい！ということでXMLでの情報取得のAPIもどきをでっち上げました。
XMLで提供する登録情報は以下
・HappyReadingのページURL
・登録したアカウントID
・本のID
・タイトル
・発売日
・ページ数
・判型
・印刷形式
・頒布価格
・キャッチ
・著者(イラストレーター、編集者、デザイナーなど)
・サークル名
・サイト
・サイトURL
・アマゾンのASIN
・カテゴリ
です。
※表紙画像や立ち読みの情報は提供していません。
https://books.doncha.net/xml.pl?bookid=839
↑このURLにbookidを指定してアクセスすると書誌情報のXMLを返します
(Firefoxなどでアクセスしてもらえるとどんなものか見えます)
https://books.doncha.net/happy-reading/detail.pl?uid=14879977&bookid=839
↑bookidというのはHappyReadingの作品個別ページのURLのbookidのことです。
このXMLを取得してページに合わせて加工することになります。
https://books.doncha.net/happy-reading/detail.pl?uid=14879977&bookid=566
このHappyReadingのページのXMLをperlで取得、アレンジして表示したのが以下です。
https://hino-yutaro.doncha.net/?happyreading=566
※表紙画像と立ち読みは別途用意してます。
phpやperlを使って取得＆加工するのが手っ取り早いですが、javascriptが使えればHappyReadingのXMLを取得できます。
はてなやFC2といったブログの場合は「HTML編集」などにしてページの好きな場所に以下のコードをコピー&ペーストすればXMLを取得してページに表示します。
先頭の「data-book="XXX"」の部分にHappyReadingのbookidを記入。
「はてなブログ」で確認。
・「編集 見たまま」でアップロードした画像を貼り付けたり、記事を作ります。
・「HTML編集」でHappyReadingの登録情報を掲載したい部分に上記のコードを(bookidを記入して)貼り付けます。
・「プレビュー」
素気ないリストでの表示なので、スタイルシートでデザインします。
・id が #happy-reading のリスト(ul)となっていて。
liに「title」「creator」「size」「printing」「pages」「price」「published」「category」「catch」「circle-name」「site-url」「amazon」「to-happy-reading」というクラスをつけてます。
表示or非表示や文字サイズ、色などをCSSでカスタマイズできます。
(わたしはデザイン力がないのでテンプレートを作る気力が…)
ハマったところがあったんでメモ。
Javascript、ajaxで別ドメインにあるXMLを取得するためにはjQuery側とサーバー側で設定が必要だった。
・jQueryのajaxのパラメータ「crossDomain」を true にする。
・サーバー側(今回の場合xml.pl)スクリプトのHTTPヘッダに
「Access-Control-Allow-Origin:*」
「Access-Control-Allow-Headers:Origin, X-Requested-With, Cotent-Type, Accept」
の2行が必要だった。
（スクリプトに付加したヘッダはなにやらセキュリティ的に不穏な感じなので、formデータのチェックを厳密にしておいた）
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
twitterのOAuthについて改めて
perlでtwitterのOAuth認証するまで概略。
（今まで何度か書いたと思って探したら、スゲーテキトーなことしか書いてなかった）
「OAuthとは」てのはわたしもよくわかってない。詳しいサイトがたくさんあるので興味のかたは検索して調べてください。
大雑把に。
ユーザーを識別するのに、IDとパスワードが必要になるんだけど「野良サービスにメールアドレスやパスワードを登録するのはどうなの？」「いろいろなところにIDやパスワードを登録しても忘れちゃうし」ということで不安だし不便。サービスを提供する側としてもユーザーのIDなどを管理するのはリスキー。
そこで、twitterやfacebook、yahoo、mixiなどすでに利用していて信用できそうなサイトにログインしたら、そのまま他のサービスも使えるようにする・twitterなどがユーザーを保証してくれるのがOAuth認証というやつ（言葉はたぶん間違ってる）
ウチの「創作文芸見本誌会場HappyReading」https://books.doncha.net/happy-reading/ で使っている。
1 同人誌の登録ページにログインする
2 twitterのログイン画面に飛ぶ
3 twitterでIDとパスワードを入力する
4 ウチのページに戻ってくる
2のこんな画面は見たことがあると思う。
・ユーザーはtwitterのアカウントがあれば、twitterのID・パスワードでウチも使える。
・ウチとしてはユーザーのIDやパスワードを管理しない（知らないまま）なのでリスクが少ない。
準備
https://dev.twitter.com/apps
↑まずはアプリをここで登録をする。
（WEBだったらCGIなどのサービス）
登録するとOAuthに使うパラメータというかトークンが設定されるのでメモ。
・Consumer key
・Consumer secret
・Access token
・Access token secret
以下のURLもメモ。
・Request token URL
ttps://api.twitter.com/oauth/request_token
・Authorize URL
ttps://api.twitter.com/oauth/authorize
・Access token URL
ttps://api.twitter.com/oauth/access_token
・Callback URL
https://example.com/test.cgi
（これは自分が登録したWEBサービスなど）
その１
consumer key と consumer secret、callback URLをパラメータに持ってtwitterにトークンを要求する。
ttps://api.twitter.com/oauth/request_token に以下のHEADERをつけてGETでアクセス。
その２
consumer key と consumer secret に問題がなければ、oauth_tokenを取得できる。
twitterのログインページ(上図 ttps://api.twitter.com/oauth/authorize)にoauth_tokenをパラメータにつけてリダイレクトする。
その３
twitterのログインページでアプリを承認をすると再びウチのページに戻ってくる。
その時、oauth_token と新たに oauth_verifier というパラメータを付けてくる。
その４
oauth_verifier をパラメータに追加して ttps://api.twitter.com/oauth/access_token にPOSTでアクセスする。
postのcontent
問題がなければ、oauth_token と oauth_secret と screen_name が取得できる。
後はこの oauth_token と oauth_secret を使って（セッションなど利用して）ユーザーがウチのサービスを使えるようにする。
補足：OAuth のパラメータ
URL
METHOD
oauth_callback
oauth_consumer_key
oauth_nonce(一意のランダムな文字列)
oauth_signature(署名)
oauth_signature_method(署名の方法 HMAC-SHA1)
oauth_timestamp(タイムスタンプ timeの出力)
oauth_version(oauthのバージョン)
署名の作り方についてはこのあたり→ 「token secretの保存」 (2009/12/26)
ここんとこ、ツイート1のスパムアカウントからのフォローが断続的に続いて、いちいち手動でスパムブロックするのが面倒になったので、一括スパム報告するスクリプトを作ってみたら…OAuthなどずいぶんいろいろ忘れてたので、備忘録。
もの忘れが激しい。とほほ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ツイートとレビューを取得する
この雑記帖スクリプトでは、公式APIが使いにくい・デザインが合わないブログパーツなどに関しては、HTMLから直接取得している。
twitterの「その他」→「ツイートをサイトに埋め込む」
この機能は便利なのに、表示・デザインに自由度がなくて、サイトに埋め込むと
このありさま。どっちが本文でどっちが引用（ツイート）なのかわからない我が侭な自己主張。ユーザビリティ、デザイン的にこれはない。
twitterとしては、表示をコントロール下において広告などで収益を視野に入れて展開したい、んだろうけど。サイトはこちらのもの。大きな顔をされては困る。
Amazon AWS の API でレビューが取得できなくなっていた（もう２年も前の話。今さら気づくのんきな父さん）
商品情報に含まれているのは、ユーザーレビューがあるかないか（true false）ユーザーレビューページのURL（24時間の期限付き）。このURLをインラインフレームで埋め込んでね、ということらしい。インラインフレーム表示させると、サイトの統一感を壊してしまって、楽天のチラシのような見た目になってしまう。
Amazonとしては、レビューの品質を上げるためにレビューをコントロール下において、レビューの精査・削除などしていきたいんだろう。
しかたないので、twitterもAmazonも公式APIを使わずに、HTMLを解析して取得、スタイルシートなど調整して、サイトにおさめるようにした（スクリプトのソースはちょっと内緒。HTMLのどこを見てるかあまりおおっぴらにするのは良くない＝ルール違反かなあ）
見やすいサイト、使いやすいサイトは、サイトに掲載される情報の分類がきちんとわかりやすくレイアウトデザインされていて、動線も明確でリンクをクリックしたら何が起こるのかわかりやすくなっている。
アートは感性・デザインは理屈。サイトもデザインと同じで、どうしてこの位置にこのブロックがあるのか、なぜ動線はこっちに向けてるのかなどなど、いちいち説明がなければならない。
情報設計＝インフォメーションアーキテクチャ＝IA というらしい。初めて聞いたときは、また妙な、きっとくだらないカタカナ言葉でひとを騙そうとしやがって、だったんだけど本を読んでみると、IAに関してはWEBに関わるひとにとって必須。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
KindleストアでKDP個人作家判定は無理？
現時点では、KDPの個人出版物を判定するのは難しい、というのがわかった。
アマゾンAWSのAPIで情報を取得してごにょごにょするのが基本。
APIで取得するXMLには商品のほぼすべての情報が入っているんだけど、kindleストアの電子書籍に関しては販売価格がなかったし、今回取得したXMLを加工なし状態で覗いたところ、どこを探してもKDP（Kindle Direct Publishing＝個人のセルフ出版物）だという要素は見当たらなかった。
法人との仕入れ契約は個人とは全然別のはずだから、裏側というかバックヤード系のデータベースにはしっかり登録されて、区別がつくようになっているんだろうけど、ショップサイドに使うデータとしてAPIでは提供されていなかった（今日時点）
APIの仕様などの一次情報はこちら「Product Advertising API」
https://images-na.ssl-images-amazon.com/images/G/09/associates/paapi/dg/index.html
とりあえずのその場しのぎで、KDPの個人出版物かどうか判定する方法としては。
・既存の出版社から出ている印刷本もあるKindle本は、アメリカのアマゾン .com では販売されていない。
・個人のKDPの場合は .com でも販売されている。
・アマゾンが管理する ASIN コードは一意のものなので、販売する国が違ってもASINは同じ。
てことで、日本のアマゾン .co.jp とアメリカの .com でASINを検索して両方で販売されていたら KDP個人出版物、だろう。
パブー経由のKindle本は、出版社ではないのに .com での販売はないらしいが、数的に取りこぼしても問題はない
スクリプトでAPIを叩いて回ってもいいし、ブラウザで日米のアマゾンを開いておいてASIN検索してもいい。
上記、ASINを入力して調べるやりかた。
でも、ひとつずつ入力するのは面倒なので、各カテゴリをリストしてその中でKDPかどうか判定して表示させたい。
と思ったら、こっちも難しかった。
たとえば「文芸・評論」→「日本文学」で絞って、APIからXMLを取得して表示させたら夏目漱石の「坊ちゃん」をはじめとする青空文庫が大量に出てきた。当然KDPではない。「有料」だけをカテゴリした BrowseNodeId があるはず、と探して回ったけど見当たらず。一括一網打尽の地引き網で有料のコンテンツだけを引っ張り出すのは無理（何か方法があれば、ぜひ教えてください）
「Kindle本のXMLに販売価格の要素がない」ことと何か関係でもあるのかな。
結局、ASINを入力してKDPかどうかを判断するスクリプトが一本できただけ…ブラウザで手作業でASIN検索することを考えると、ほんの少しだけラクかも知れないけど、あまり役に立たないなあ、とガッカリ。
- 『おかえりください』サウンドノベルWINDOWS版
- 『おかえりください』本編を加筆修正、６つのバッドエンド分岐シナリオを追加してサウンドノベル化！
音と映像が、血まみれのこっくりさんの惨劇を蘇らせる。 - 【無料体験版】はこちら
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
kindle本の価格が取得できない
AWSのAPIで取得するXMLの中には listpriceという要素があって、これが表示販売価格。なんだけど。kindle本に関してはXMLのどこにもlistpriceが存在しない。
AWSのAPIではkindle本の価格が取得できないのだ。
あれ？ほんまかいな、と検索かけまくったところ、AWSのDiscussion Forums の書き込みを発見。
https://forums.aws.amazon.com/thread.jspa?messageID=395843
「In Product Advertising API(JP), there is no price of kindle ebooks」
2012年10月25日の書き込みで、今日時点まだ解決していない。
AWSを使ったWEBサービスで金額が表示できないのは困る。値段のわからないものなど見に行く気にならない。商品にとって値段というのは重要情報。
てことで、ASINを元に、まずAWSのAPIにリクエストして販売価格以外の情報を取得。次にASINを元に本の詳細ページをwww.amazon.co.jpにリクエストして、HTMLをパースして価格を取得。
とかやってみたんだけど、ひとつの本の情報を取るために2回もHTTPリクエスト。って、そもそも、取得したいのは、自分でKindleストアに並べた本＝自分で各種情報も定価も知ってるウチのkindle本だ。こりゃどう考えても無駄だし、ページが重くなるだけだった。
AWSの規約ではASIN以外のデータは24時間以上キャッシュしてはいけない、となっている。時間を見るようにするか検討しつつ、スクリプトの設定ファイルに本の各種データを登録して、そっちをまず利用するように変更した。
でも、なんでまた、Kindle本のXMLには価格が入ってないんだろう。バグか仕様か微妙な感じ、だ。
そういや。12月１７日に KDPセレクトで無料キャンペーンや70%著者印税 で、初めて無料キャンペーンを１日やった時は30冊ほどダウンロードされて、意外と効果がありそう、などと言ってしまったけど、その後2回ほどやった時は、海外アマゾンも含めて10冊程度しかダウンロードされなかった。同じ間隔でtwitterにbotで告知を流したので条件は同じはず。2回目ってことで新鮮味がなかったか。
もし次、別の本でやるときはちまちま分けずに１回で５日間を使い切る感じでやってみるか。
いろいろ試行錯誤は続くなあ。
- 『おかえりください』サウンドノベルWINDOWS版
- 『おかえりください』本編を加筆修正、６つのバッドエンド分岐シナリオを追加してサウンドノベル化！
音と映像が、血まみれのこっくりさんの惨劇を蘇らせる。 - 【無料体験版】はこちら
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
twitter API 1.0から1.1へ移行メモ
12日の明け方に、今まで使えていたエンドポイント（APIのURL）が使えなくなりあちらこちらで話題になっていた。具体的には
ttp://twitter.com/statuses/user_timeline/NNNNNN.xml
が使えなくなり
ttps://api.twitter.com/1/statuses/user_timeline.json
ttps://api.twitter.com/1.1/statuses/user_timeline.json
と、APIバージョンつきのURLを使ってね、ということ。
twitter公式発表だと、API 1.0 が使えるのは2013年3月までなので、この際ウチで使ってるtwitterのAPIなども1.1に変更した。
一次情報はこちら
https://dev.twitter.com
https://dev.twitter.com/docs/api/1.1
今まで意図通りに動いているスクリプト類は、1.1のエンドポイントに変更するだけでほぼOK。心配するほど大きな変更はなかった。
うちの場合データ取得などは、すべてXMLでやっていて、公式発表によると、RSS XMLは廃止、なので、jsonでの取得に切り替えた。twitterの公式ページには具体的なリクエストやパラメータなどが載っていて、サンプルもあって助かった。
mentions → mentions_timeline とバージョン番号の有無以外に変更になったAPIや廃止されたAPIもあるので、それは公式サイトを参照ください。
perlで作ったスクリプトでひとつひっかかったのがPOST。
1.0と同じデータを1.1のエンドポイントにリクエストすると、BadRequest 400が返ってくる。code 215エラーとか。1.0だと問題なかったのになんじゃそりゃ、と検索しまくってもそれらしい問題は出てこない。GETで取得するものは大丈夫。てことはOAuthでPOSTのリクエストに変更があったのか、と公式ページから辿ってみるとOAuthに関して、1.1は1.0よりもstrictになったらしい。でも、それならほかの開発者からも呪いの声が上がってるはず。公式ページを読んでも、OAuthのデータの作り方は今までと同じで問題ない。
あれこれ検索したり、CPANからNet::Twitterをダウンロードして眺めてみて、結論。
画像など添付のため、multipart form-data形式でのPOSTを受け付けるようになっていて、このPOSTは form-data なのか普通の（？）application/x-www-form-urlencoded なのかを明示する必要があったようだ。
これまでHTTPのヘッダのcontent_typeは何も指定せずそのまま通ってたんだけど
と、指定することで無事解決。…ほぼ一日ハマってしまった。
POSTリクエストの一次情報はこちら
https://dev.twitter.com/docs/auth/creating-signature
昨日、WEBの表に出てるところは、すぐに気づいて直してまわって、やれやれ終わったぜ、と思ってたら、cronで使ってるものがあってすっかり忘れてた。
cronで使ってたのは 「趣味は読書２」 という公開中のWEB本棚サービスのtwitter連携。
twitterで本のタイトルや、著者名をつぶやくと、その本がすでに本棚に入ってるかどうかをリプライする。二重買い防止のため、本屋さんなどで「うーん、これ読んだっけ？」な時に重宝してる機能だった。
- 『おかえりください』サウンドノベルWINDOWS版
- 『おかえりください』本編を加筆修正、６つのバッドエンド分岐シナリオを追加してサウンドノベル化！
音と映像が、血まみれのこっくりさんの惨劇を蘇らせる。 - 【無料体験版】はこちら
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
