ソースヘッダ
あるプロジェクトで Eclipse のテンプレートとしてこんな感じのを使えという規約がある。
/* * システム : うんたらかんたら * ファイル名 : ${file_name} * * {コピーライトとかの提携文} * * DATE: ${date} * Created by: ${user} */
えーっと、おいら新しいクラスを作るときにわざわざメニューから New->class なんて選ばないんですが。最初の一個目のベースクラスはともかくとして、以降はそのクラスを開いた状態で実装が必要なメソッドを埋めていくの。
何でソースファイル上にファイル名を書かせたがるんだ?めんどくさくてしょうがないっつーの。$Id:$ ならほっとけばいいんだが。
当然のことながら ${date} も嘘だらけになる。こういうのはソースコード管理システムに任せるべきでしょ。
atom …
まぁこれまで無視されてきたメソッド群に復権をって感じですか。
しかし XML-rpc にせよ、やっぱり普及させるのは難しそう。
soap をはじめとする web-services はもとより、XML-rpc ですらその冗長なペイロードのせいでむやみに実装負担が増えていて、ライブラリが少々整備されたくらいでは莫大な普及は難しいと思う。
atom はその辺を鑑みて策定されているので当然実装は簡単で、簡単な操作なら GET/POST でできることがかなりの優位点と思うけど、惜しいのはまさしくその「無視されてきたメソッド群」を使おうとしてしまったこと。
GET/POST だけで API を構成すればブラウザで直接 API を叩けるので、日曜プログラマでも思いつきでデバッグ/お試しできるという点で敷居がおもいっきり下がるのではないかと思うのだけど。
atom にも対応しようかと思ったけれど、Mechanize の仕組みで十分という気がしてきた。
というか自分が HTTP ベースのアプリケーションプロトコル作るときは間違いなく GET/POST だけの構成にしてきたしな。REST ってそういうものと思ってたけど、違うのか…?
(追記)
cookie / redirect / refresh の追跡は対応させたけど、JavaScript で遷移しているところまでは対応させるのきついなぁ。ブラウザを内部的に起動しちゃってロボット操作するように作れるなら完全にエミュレーションできるんだけど。>Mechanize
今度は WWW:Mechanize
perl の WWW:Mechanize 相当を Java で作った。
典型的な使用感はこんな感じ。
public static void main(String[] args) throws Exception { HTML html = new HTML("http://www.yahoo.co.jp/"); System.out.println("[title]" + html.getTitle()); System.out.println(html); Form form = html.getForm(0); form.setParam("p", "テスト"); html = form.submit("search"); System.out.println("[title]" + html.getTitle()); }
リンクとフォームを追いかける。multipart/form-data の POST にも対応した。
ってことではてなへの投稿でも試してみるかな…。