拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
N10K 掲示板 Mojolicious::Lite app - Tociyuki::Diary
半分ネタ半分本気のウェブ掲示板スクリプトです。名前の通り 1 万件 (N10K) を越えるエントリを投稿・閲覧可能な掲示板です。データは平文のテキスト・ファイルに保存する作りで、掲示板としては、とてもシンプルでたいしたことないのですが、莫大なエントリを食わせても余裕で閲覧・投稿・削除をおこなえるのがポイントです。といっても、速度が落ちないからと調子に乗って食わせていくと、データ・ファイルのサイズが数百メガバイトに膨れ上がっていくので、128メガバイトの容量制限と10万件のエントリ数制限をかけています。 このスクリプトはコンセプト・スクリプトでありエラー処理が甘いため、インターネットで公開して使わないでください。ローカルマシンで遊ぶ程度にしておいてくれた方が書いた私も安心します。 投稿制限は、ホワイト・リストによる URL 制限と、行数を漢字60文字を一行分として文字数と改行数から計算し、3
Perl で簡単にパーザを書く - tokuhirom's blog
パーザを書こうという場合、Parse::RecDecsent のようなモジュールを使うのが一般的だが、Perl5 の正規表現は強力すぎるため、そんなものに頼らなくても超絶簡単にパーザを実装することが可能だ。 以下に、四則演算のパーザを示す。 use 5.018000; package Calc { use Carp (); sub parse { local $_ = $_[1]; _parse_expr(); } sub err { my ($msg) = @_; my $ret = join('', $_, "\n", (" " x pos()) . "^\n", $msg, "\n", ); Carp::croak $ret; } sub _parse_expr { my @nodes; until (/\G\s*\z/gc) { my $m = _parse_add() or do
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
