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

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

おまえんち、そんなにアクセスないくせに、高いサーバ買おうとしやがって、といわれたら、どう返したらよいのか。という話。