InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example
ここ数年,小規模なサービススイートで構成されたアーキテクチャを表現することばとして"マイクロサービス"という用語が拡がっている。QCon San Francisco 2012でもThoughworksのJames Lewis氏が,このテーマでプレゼンテーションを行った。氏はMartin Fowler氏と共同で,同じテーマの記事も書いている。これに対して,マイクロサービスは一部の人々が考えるような新しい概念ではない,所詮はSOAの焼き直しに過ぎないという意見を持って,最近この議論に加わったのがSteve Jones氏だ。その中で氏は,Lewis氏とFowler氏の記事の分析を順に追いながら,両氏のマイクロサービスの定義をOASIS SOA RM(Reference Model, 参照モデル)と比較する,という作業を行っている。 サービスによるコンポーネント化: OASIS SOA RMによる
HerokuのAPIチームの一員、Wesley Beary氏がHTTP+JSON API作成のためのガイドラインを要約した形でまとめた。 これは一般的な推奨からはじまっている。 API呼び出しはすべてTLSを使う必要がある。非TLSの呼び出しには403 Forbiddenを返す。 APIには必ずバージョンを付けること。バージョンの指定にはAcceptヘッダを使う。デフォルトバージョンに頼る代わりに、クライアントはAPIバージョンを指定する必要がある。 リソースのキャッシングをサポートするために、ETagヘッダを使うこと。 X-Request-IDの付いたレスポンスを識別すること。これはログやデバッグに役立つ。 大きなレスポンスを扱うために、Range、Content-Range、Next-Rangeを使うこと。 リクエストについて、次のように述べている。 以下のような適切なステータスコード
ソフトウェア開発者のEvan Cordell氏は数週間前のAPI-Craftメールリストで,ハイパーメディアのREST制約は一般的なWeb API要件とどのように違うのか,という議論の口火を切った。 "REST主義者的危機(RESTistential crisis)"と題した論議の中で氏は,長年の議論と実践によってRESTスタイル最大の秘密,ハイパーメディア制約が明確になり始めたことを指摘している。Webでも明らかなように,人間中心のインタラクションには完璧に対応しているが,その一方でプログラマブルなWeb API一般においては,有用性に対する懸念がWeb APIコミュニティの中で増しつつあるようなのだ。 RESTに関する説明,ドメイン特有のWeb APIに適用した場合のハイパーメディアの制限,といった話題から始まった今回の議論では,新たなアーキテクチャスタイルの必要性の検討や,RESTを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く