Re: お邪魔します。

ドラちゃんさん、こんにちは。

賛同者(と思っていいですよね?)が現れてうれしいです!

例えば、
http://www.seg.co.jp/sss_review/jsp/frm_a_120.jsp?cd_syuppan=0000002576
の代わりに
http://www.seg.co.jp/sss_review/jsp/frm_a_120.jsp?cd_syuppan=0000002576&type=xml
としてhttpリクエストを投げればxmlでデータが
返ってくるだけで十分というか、これこそAPIだと
思います。

Amazon WebServicesも同様のインタフェースですよ。
もちろんAmazonのほうはリライアビリティは
ずっと高いのでしょうけれど。

　yhiroakiさん、こんにちは。ドラです。

〉賛同者(と思っていいですよね?)が現れてうれしいです!

　えぇっと…私自身は賛同しているつもりです。

〉例えば、
〉http://www.seg.co.jp/sss_review/jsp/frm_a_120.jsp?cd_syuppan=0000002576
〉の代わりに
〉http://www.seg.co.jp/sss_review/jsp/frm_a_120.jsp?cd_syuppan=0000002576&type=xml
〉としてhttpリクエストを投げればxmlでデータが
〉返ってくるだけで十分というか、これこそAPIだと
〉思います。

　そうですね。APIの追加だと、そんな感じですよね。
　ただ、私が書いていた事は、実はちょっと違っていて、既存の

　　http://www.seg.co.jp/sss_review/jsp/frm_a_120.jsp?cd_syuppan=0000002576

といったURLで生成されるHTML文の中に、既にXMLタグが埋め込まれている形に
したら、何か支障があるかなぁ…と思っていたんですよ。セキュリティ要件
とかは、外から見てる分には特に無さそうですし。

　それで、もしこういうやり方で済めば、インターフェースの追加が発生しない
ので、機能追加に対する工数が少なくていいかと思っていたんですけれど。

＃ まぁ、これはあくまで思いつきなので、
＃ 実際にはダメな点があるのかもしれない
＃ んですけれど。あるいはソースが分散
＃ していて、メンテしにくいとかいう
＃ 事もあり得るので、一概には言えない
＃ とは思っているのですけれど。

　もし、見当外れでしたら、ごめんなさいね。

〉Amazon WebServicesも同様のインタフェースですよ。
〉もちろんAmazonのほうはリライアビリティは
〉ずっと高いのでしょうけれど。

　まぁ、そうでしょうね。サーバの構成からして全然違ったものでしょうから。
　Amazon のレンタルサーバ事業で、ハード面・回線面では、その堅牢さの恩恵に
あずかれるようになったとは言え、やはり大事なのはソフトですから。

こんにちは。

"yhiroaki"さんは[url:kb:1143]で書きました:

〉例えば、
〉http://www.seg.co.jp/sss_review/jsp/frm_a_120.jsp?cd_syuppan=
〉の代わりに
〉http://www.seg.co.jp/sss_review/jsp/frm_a_120.jsp?cd_syuppan=0000002576&type=xml
〉としてhttpリクエストを投げればxmlでデータが
〉返ってくるだけで十分というか、これこそAPIだと
〉思います。

http://www.seg.co.jp/sss_review/jsp/review.jsp?cd_syoseki=0000001664

で、レビューの XML が返ってくるのと同じイメージでしょうかね。
( 非公開APIかな? )
SOAPとか言い出すと面倒なことになりそうですが...

ドラちゃんさん、スニフさん、こんにちは。

ドラちゃんさん、失礼しました。
普通の閲覧用ページの中で情報にタグをつけておく、
という意味だったんですね。なるほど。
解析にひと手間かかるので（と言ってもタグ以外は読み飛ばす、
というフィルタをかけるくらいかもしれないですが）、
できればxmlがいいですねえ。
ご指摘のとおり、費用対効果ということになるのでしょうけれど。

スニフさん、そのイメージです。
レビューについては、そういうアクセス方法が既にあるんですね。
実はレビュー以外の情報用も用意されていたりして・・・。
SOAP等は呼び出すほうも呼び出されるほうも実装が大変になると
思うので僕は要望する気はないです。基本的にはRESTを志向しよう
という思いもあり。