10周年のSPコンテンツ!

図書館等のサービスAPI公開時・利用時に考えたいこと

NDLのAPI公開に関連して、公開側で考えておきたいこと、利用(開発者)側が受ける影響など、興味深いツイートの流れだと思ったので、まとめました。 円滑・円満にサービス提供・利用するという意味ではよく考えて、かけられるコスト(予算だけでなく人的なものも)、過負荷による停止時の免責事項、そして何よりも「目的」を果たすためにも。。
API 図書館サービス 利用制限
5
RAKUSAI Isshu @rakusai
ITシステムは未完の技術だという認識が必要です。例えるならば、家の中で大量に電力を消費する機械を設置して遊んでいたら、電気会社が止まってしまったということです。今のサーバーっていうのはその程度なんです。 #librahack
RAKUSAI Isshu @rakusai
そのブレーカーがないのが問題 RT @gutei #librahack 微妙な例えな気が…その前にブレーカー落ちまくるんじゃないかと思ってみたり… RT @rakusai: ...例えるならば、家の中で大量に電力を消費する機械を設置して遊んでいたら、電気会社が止まってしまった
Satoko Hara @satk108
ここにもAPIあります。 QT @ca_tweet: 国立国会図書館「リサーチ・ナビ」が検索用APIを公開、PORTAでも検索可能に http://current.ndl.go.jp/node/16449
RAKUSAI Isshu @rakusai
まだ「大量アクセス禁止」とか言っている.怖くて使えないよ RT@satk108 ここにもAPIあります。QT@ca_tweet: 国立国会図書館「リサーチ・ナビ」が検索用APIを公開、PORTAでも検索可能にhttp://current.ndl.go.jp/node/16449
Toshiyasu Oba @tsysoba
PORTAも原則大量アクセス禁止ですが、可能性がある場合には事前に相談してください、というスタンスです。「このサイトについて」→「外部提供インタフェースについて」
RAKUSAI Isshu @rakusai
「大量アクセス禁止」と書かれたAPIは使えない。APIサーバーがただの箱になるか、NDLの正念場。開発者はテストのときにバグもだす。そのリスクを押し付けている。 http://current.ndl.go.jp/node/16449
FUKUSIMA,Yukihiro @archivist_kyoto
この話直接やってるのかな? QT @rakusai: 「大量アクセス禁止」と書かれたAPIは使えない。APIサーバーがただの箱になるか、NDLの正念場。開発者はテストのときにバグもだす。そのリスクを押し付け… http://current.ndl.go.jp/node/16449
Toshiyasu Oba @tsysoba
@archivist_kyoto まあ、ほとんど直接やってるのと、同じことかも。
FUKUSIMA,Yukihiro @archivist_kyoto
@tsysoba まあ、そんならいいんですが。われわれには試金石になるので。
RAKUSAI Isshu @rakusai
いえ、一開発者としてのコメントです。RT@archivist_kyoto この話直接やってるのかな? QT @rakusai: 「大量アクセス禁止」と書かれたAPIは使えない。APIサーバーがただの箱になるか、NDLの正念場。開発者はテストのときにバグもだす。そのリスクを押し付け
Toshiyasu Oba @tsysoba
API出すなら、アクセスされる側で何とかせいや、ってことか……。
FUKUSIMA,Yukihiro @archivist_kyoto
あ、どうも。お仕事、注目しております。いや、大事な問題なので、直接やりとりされてはどうかなあ、と QT @rakusai: いえ、一開発者としてのコメントです。QT archivist_kyoto QT @rakusai: …APIサーバーがただの箱になるか、NDLの正念場。
Miyagawa Yoko @yoshim32
APIがどーのという以前の話として、自分ちの適正アクセスとか考えて設計してるのかな、みんな。うちだけダメダメ、っていういつものパターン?
@satk108
そのへんの表現は、前例を踏襲しただけのものが残っている可能性があります。今後出すものは再検討しようと思います。結果どうなるかはわかりませんが、きちんと検討すること自体が前進だったりします。歩みが遅くてお恥ずかしいですが。
Toshiyasu Oba @tsysoba
@yoshim32 一応の性能要件は設計に組み込まれるのが筋ではあるのですが…。上限は必要だけど、それをアクセスする側でコントロールせよ、といっているところが問題なのかと。
Miyagawa Yoko @yoshim32
@tsysoba あ、わかりにくいつぶやきをしてしまい、すみません。目下、その性能要件をどうやって固めるか、を思案中でして。
Miyagawa Yoko @yoshim32
何があってもどんとこい!な高性能にしたくても、財政的に許されない。かといって、実績ベースで算出して、某市みたいなことにも対応できないようでは。。。
Toshiyasu Oba @tsysoba
@yoshim32 ああ、こちらこそすみません。確かに、同時に何人のどのくらいの頻度のアクセスまで対応するか、というのを、根拠を持って示すのは難しいですよね…。
Toshiyasu Oba @tsysoba
@yoshim32 余談ですが、某件のようにシステムが落ちる落ちないの話と、落ちてないけど検索結果は返せない(返さない)、というのは、本来は別のことなんだろうと思います。ついついごちゃまぜになっちゃうんですが。
RAKUSAI Isshu @rakusai
開発側がコントロールすることは不可能ではないが、その仕組みを作るのは大変。カーリルではまさにそのあたりを開発者のためにやってる。 RT @tsysoba @yoshim32 …上限は必要だけど、それをアクセスする側でコントロールせよ、といっているところが問題なのかと。
RAKUSAI Isshu @rakusai
制限超えたらちゃんとエラーを返す仕組み(例えるなら「整理券」使って入場を適正化)があれば、問題ない。許容値はテストすれば割りだせる RT@tsysoba @yoshim32 ...同時に何人のどのくらいの頻度のアクセスまで対応するか、というのを、根拠を持って示すのは難しいですよね
RAKUSAI Isshu @rakusai
対策法はともかく一番問題なのは、API提供がこういう態度だと、開発者の発想がすごく制限されちゃう。大量アクセスしないサービスしか発想できない... こんなAPIが日本に普及しても今と何もかわらない。カーリルは安泰かもしれないが^^;
Toshiyasu Oba @tsysoba
@rakusai @yoshim32 仕組みと、既存のシステムでの許容値の割出しは、何となく分かります。すぐ出来るかどうかは、また別の話ですが…。それと開発の調達時にどう性能要件を書き込むかは、別の問題かと。
Miyagawa Yoko @yoshim32
. @tsysoba うちのレベルだと、エラーを頻繁に返して、「ここんちのページ使えねーな」と呆れられないためには、どうしたらよいのかを思案中。で、NDLさんのAPIの話は、その先の段階かと。
Miyagawa Yoko @yoshim32
おまえんち、そんなにアクセスないくせに、高いサーバ買おうとしやがって、といわれたら、どう返したらよいのか。という話。
残りを読む(3)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?

ログインして広告を非表示にする
ログインして広告を非表示にする