BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル 紹介:Restful Objects

紹介:Restful Objects

原文(投稿日:2012/07/19)へのリンク

Restful Objectsは、ドメイン・オブジェクト・モデルのハイパーメディアAPIの公開仕様である。仕様のバージョン 1.0.0は、リリースされたばかりで、ここからダウンロードできる。すでに仕様を実装した2つのオープンソースフレームワークがあり、1つはJavaプラットフォーム用で、もう1つが.NET用である。

Restful Objectsが他のRESTfulの標準やフレームワーク、例えば、Javaプラットフォーム用の JAX-RS (JSR311) 、あるいは、.NET用のMicrosoftのWeb API とどのように違うのか?そのようなフレームワークは一般的に、純粋なネットワークの問題を抽象化するのに役立つが、さまざまな種類のドメイン・オブジェクトのとやり取りするために、定義されたリソース構造における、いかなる統一性も保証しない。そして、ほぼ間違いなくRESTfulシステムの最も重要な原則である、「アプリケーション状態のエンジンとしてのハイパーテキスト」すなわちHATEOASをほとんどか全くサポートしていない。平易な言葉で言えば、これは、ホームリソースからのハイパーメディア・コントロール(リンク)を追うだけで、システム全体の機能にアクセスすることが可能であることを意味する。おそらく Restful Objectsがしようとしていることに最も近いのは、ODataである。しかし、大きな違いがODataのが実際にCRUD(作成、読み取り、更新、削除)機能を対象としているのに対して、RESTfulなオブジェクトは、オブジェクトの完全な動作(メソッド)へのアクセスを提供する。

Restful Objects仕様を実装する新フレームワークは、ドメイン・オブジェクト・モデルへの HATEOAS準拠APIを書く仕事を容易にはしてくれない。それらは、実際、そのような仕事を無くしてしまう。文字通りドメイン・オブジェクト・モデルが手にでき、POJOあるいは、プレーン・オールドなC#オブジェクトとして書け、それらに完全にRESTfulなAPIを数分で作成できる。

さらに、これらのフレームワークによって提供されるリソースや表現が公開された仕様に準拠しているので、1つのフレームワークを実行するサーバーで動作するように書かれたクライアントは、他で動作することを意味します。私たちの願いは、今後数ヶ月にわたって、 Restful Objects仕様のサーバー側の実装が増えることだ(我々は少なくとも1つのグループがそうしよう、と計画しているのを知っている)。我々はもうすぐ、 Restful Objects APIを利用する標準的なクライアント側のフレームワークが出現してくるのが見れるだろう。

適用性とメリット

Restful Objects仕様は、ドメイン駆動開発(DDD)を使っていたり、従ってドメインオブジェクトモデルを持っていたり、あるいは開発している、そしてまた、このモデルにある種の RESTful APIを提供したいと思っている開発者に、アピールする可能性がひじょうにある。DDDの我々自身の経験には、非常に大規模なドメインオブジェクトモデリング[1, 4, 5]が含まれており、動きの大部分は、ドメインエンティティのメソッドとしてカプセル化されている。我々は、そのようなドメインモデル資産を更に活用するために Restful Objectsを使うことを楽しみにしている。

工数上の大きな削減以外に、Restful Objects仕様を実装したフレームワークを使うことで得られる恩恵には、以下のものがある。

  • テスト:すべてのビジネスロジックが、ドメイン・クラスのみで表現されているので、そのようなビジネス・ロジックは、高速かつ安価なメモリ内のユニット・テストを使用してテストすることができる。対照的に、もしRESTfulなAPIがカスタムに書かれており、特定のユースケースに合わせて調整されている場合は、Webサーバを跨いだ(より遅い)統合テストによってのみ、効果的にテストできることになる。
  • 文書化: Restful Objects はドメイン・オブジェクト・モデルにより駆動されているので、それは確立された技術(例えば、UML、または単にJavadoc /Sandcastle)を使用して文書化することができる。これは、手作りのRESTfulなAPIを明示的に文書化するために何か新しい表記法を発明するよりもはるかに望ましい。

先に進む前に、我々はまた、Restful Objects はドメインオブジェクトモデルのセマンティクスに関して不可知論者であることを言う必要がある。なので、ドメインオブジェクトは、ビジネスの実体を表すべきであること、またはユースケースの事実を表す別の「リソース・モデル」が存在すべきである、とあなたが信じているなら、Restful Objects仕様は、等しく適用可能である。単純化するために、この記事では主に前者を想定して例を示します(エンティティとしてのドメインオブジェクト)を使用するが、我々は記事の後半でこのトピックを再び取り上げる。

リソース

Restful Objects仕様では、各ドメインオブジェクトは、リソースである。例えば、以下のURIは、31のIDを持つ顧客に対応している。

~/objects/customers/31 

ここで~はサーバのアドレス(例えば、http://myserver.com), customersはオブジェクトのタイプを定義し、31は、その型の「インスタンス識別子」である。仕様では、この識別子の形式を定義していません。任意の一意の文字列がであれば良い。/objectsがなぜ必要なのか?これは他のトップレベルのリソースと区別するためである。例えば services (メソッドを持つがプロパティを持たないリポジトリやファクトリのようなシングルトン オブジェクト)や domain-types (タイプ メタデータ)。これらトップレベルのメタデータのそれぞれは、独自のサブリソース構造を持つ。

各オブジェクトリソースは、いくつかのサブリソースを持ち、これがそのオブジェクトのメンバーを表している。なので、

~/objects/customers/31/properties/dateOfBirth

は、特定の顧客の誕生日を示すが、

~/objects/customers/31/collections/orders

は、その顧客に関連した Ordersのコレクションを表す。下のテーブルは、オブジェクト、プロパティ、コレクションの各リソースにアクセスするのに使われるHTTPメソッドに対してマップされた、各リソースを示している。

 

Object
リソース

Object
プロパティ リソース

Object
コレクション リソース

GET

オブジェクトの概要

プロパティの詳細および値

コレクションの詳細および内容

PUT

複数のプロパティ値を更新するまたはクリア

値を更新またはクリア

(コレクションが集合セマンティクスを持つ場合)、オブジェクトを追加する

DELETE

オブジェクトを削除する

値をクリアする

コレクションから値を除く

POST

n/a - 405

n/a - 405

(コレクションがリストのセマンティクスを持つ場合)オブジェクトを追加する

上記の分析は革新的ではない。多くのカスタムメイドな RESTful APIが似たようなフィーチャを持っている。しかしRestful Objects仕様は、オブジェクトの「アクション」に同じアプローチを適用するのに、新しい領域を切り開いた。すなわち、オブジェクトのメソッドのアクションは、 RESTfulインターフェースを通して、アクセスできるべきである。他の設計で(例えば[2]で)これが取り組まれている範囲では、通常、アクションの呼び出しは、 HTTP POSTにマップされる。我々の目標は、オブジェクトアクション(パラメータセットが必要なもの)についての情報提供と実際にアクションを呼び出すことをはっきり区別することだ。こうして、URL

~/objects/customers/31/actions/lastOrder

は、顧客31の最後のオーダーを読み出すアクションを記述し、一方

~/objects/customers/31/actions/lastOrder/invoke

は、このアクションを呼び出すリソースである。

我々はまた、全てのアクションをPOSTで呼び出すことを要求するのは、HTTPの正しい使い方でないことを認識した。冪等アクションあるいは、ただ他のオブジェクトを呼ぶだけのクエリアクション(時々「副作用なし」と書かれる)は、どうだろうか?以下のテーブルが我々がいかに、このことを解決したかを示している。

 

Object Action リソース
(情報)

Object Action Invoke リソース

GET

起動用のパラメータやHTTPメソッドのような詳細を持っているアクションプロンプト

Invoke - もしアクションがクエリのみであることがわかっている(副作用無し)なら

PUT

n/a - 405

invoke - もしアクションが冪等あることがわかっているが、クエリのみでないなら

DELETE

n/a - 405

n/a - 405

POST

n/a - 405

Invoke アクションがクエリのみでも、冪等でもない、とわかっている場合

あるドメインモデルでは、動き(ビジネスロジック)のほとんどがサービス上に実装されていて、サービスアクションへ、あるいはサービスアクションから渡されるデータ構造のように振る舞うドメインエンティティを伴う。 Restful Objects仕様は、このパターンにうまく対処している。唯一の違いは、URLがドメインオブジェクトインスタンスではなく、サービスインスタンスを識別することである。しかし、仕様は、1つのパターンに等しく上手く対処しているので、動きの殆どは、「動きがリッチな」ドメインオブジェクト上のメソッドとして、実装されている。その結果、サービスの役割は、オブジェクトへのアクセスを提供するようなずっと小さなものである(既存のオブジェクトを見つけ出す、あるいは新しいものを作成する)。

表現

それぞれのリソースは、表現を返す。 Restful Objects仕様は、これらの表現は、JSON (JavaScript Object Notation)形式である、と定義している。 PUT や POSTメソッドで呼ばれたリソースに対して、表現もまた、どのようにリソースが修正されるべきかを記述し、リクエストへのボディとして提供されなければならない。

仕様は、若干の主要な表現を定義している。

  • object (あらゆるドメインオブジェクトかサービスを表す)
  • list (他のオブジェクトへのリンクの)
  • property
  • collection
  • action
  • action result (典型的にはobjectlistあるいは、単にフィードバックメッセージを持っている)

: そして、仕様はまた、若干の2次的な表現、例えば、homeuserを記述している。これらの表現のそれぞれは、公式なメディア・タイプを持ち、HTTPContent-Type ヘッダー中に見える。ドメインオブジェクトに対しては、これは以下の形式を取る。

   application/json;profile="urn:org.restfulobjects:repr-types/object";
   x-ro-domain-type="http://~/domain-types/customer"

公式には、これはapplication/jsonタイプであり、2つのオプションのパラメータ、profilex-ro-domain-typeを持っている。これら2つのパラメータは、消費するクライアントに追加のセマンティックスを提供し、1つがもう1つの上に存在する階層化されたもの、と考えることができる。最下層レベルでは、application/json は、クライアントに単に、ペイロードがJSONであることを言っているに過ぎない。ブラウザへの開発者プラグインのような、あるクライアントに対しては、これが必要とされる全情報である。この上に、 profile パラメータが表現がドメインオブジェクトのタイプであることを示す。最後に、x-ro-domain-typeパラメータがオブジェクトのタイプ、この場合は、Customerを示す。クライアントは、これを使ってユーザーインターフェースをカスタマイズしたり、単に返された表現が期待したものかどうかを確認する。ちなみに、仕様は.x-ro-プレフィックスを使って、利用できる既存の、あるいはドラフトの標準が無いときはいつも、名前空間の衝突を最小化している。これによって、必然的にいくつかのカスタムパラメータやクエリ文字列を生むことになる。一方、 Restful Objectsは、カスタムHTTPヘッダーを全く定義していない。

リンク

HATEOASの原則に沿って、それぞれの表現は、他のリソースへのリンクを持ち、これらのリンクのそれぞれは、関係の性質を定義したrelパラメータを持っている。仕様は、いくつかのIANA-定義の rel values値(例えばself, up, describedby)、更に幾つかのカスタム値を再利用している。例えば、

   urn:org.RESTfulobjects:rels/details;action="placeOrder"

は、オブジェクト表現からそのオブジェクト上でのアクションのリソースへのリンクを定義する。接頭辞:

   urn:org.restfulobjects:rels/details

は、一般的なクライアントには充分であるが、追加のパラメータアクション、この場合このリンクがplaceOrder アクションのものであることを示しているが、特別なクライアントに使用されることがある。

上記のことを全て一緒にして、下記のテーブルがあるユーザー目標を達成するための、リソースセットに依る典型的なワークフローを示している。

説明

メソッド

URL

ボディ

返された
表現

ホームリソースへ移動する

GET

http://~/

-

ホームページ

利用できるサービスのリストへのリンクをたどる

GET

http://~/services

-

リスト(サービスへのリンク)

ProductRepositoryサービスへのリンクをたどる

GET

http://~/services/ProductRepository/

-

サービス

「名前で検索」アクションへのリンクをたどる

GET

http://~/services/ProductRepository/
 actions/FindByName

-

アクション(ダイアログとしてUIでレンダリングされる)

この(クエリのみ)アクションを"cycle" パラメータで呼び出す

GET

http://~/services/ProductRepository/
 actions/FindByName/
 invoke/?Name=cycle

-

マッチした製品オブジェクトへのリンクのリストをインラインしたアクション結果

コレクション内の製品のいずれかのオブジェクトへのリンクをたどる

GET

http://~/objects/product/8071

-

オブジェクト(製品を表す)

このオブジェクトの(ゼロパラメータ)のアクション‘AddToBasket’を呼び出す

POST

http://~/objects/product/1234/
 actions/AddToBasket/invoke

-

-

BasketService上の ‘ViewBasket...’アクションを呼び出す

GET

http://~/services/BasketService/
 actions/ViewBasketForCurrentUser/
 invoke

-

Itemオブジェクトへのリンクのリストをインラインしたアクション結果

追加したばかりのアイテムの数量プロパティを変更する

PUT

http://~/objects/orderitem/1234/
 properties/Quantity

value=3を表現するプロパティ

-

Basketから(以前追加された)アイテムを削除する

DELETE

http://~/objects/orderitem/517023

-

-

サーバーの実装

前に、 Restful Objects仕様を実装した2つの異なるオープンソースフレームワークに土て述べた。Restful Objects for .NETは、仕様の完全な実装で、ベータ段階にあるが、その理由は、Microsoft Web APIフレームワークを使用しているためだけである(ASP.NET MVC4の一部で執筆時点では、'RC'ステージ)。2つ目のフレームワーク、Restful Objects for Isis は、Javaプラットフォーム上で走る。このフレームワークが動作しているが、現在、仕様の以前のドラフトを実装し、リリースの前にさらなる開発とテストを必要とする。我々は積極的にこれらのフレームワークの開発に関与している。

これらのフレームワークのどちらを使っても、ドメインオブジェクトモデルをPOCOかPOJOとして書き、 それ以上のコードを書かずに、Restful Objects仕様に従った完全な RESTful APIを作成することは、可能である。オンラインビデオ (.NETフレームワークを使って)がほんの数分でこれが済むことを示している。

これが出来る理由は、両方のフレームワークは、裸のオブジェクトパターンを実装している既存のフレームワークの上にできており、オブジェクト指向ユーザーインターフェースは、リフレクションを使ってドメインオブジェクトモデルから自動的に作成され、(既定で)公開メソッドは、ユーザーアクションとして、利用できる。新 Restful Objectsフレームワークは、同様なやり方で、ドメインオブジェクトモデルに反映するが、オブジェクトの能力を、ユーザーインターフェースでなく、 RESTful APIとして表す。両方のケースとも、リフレクション、オブジェクトの永続性、他の分野横断的な懸念事項の責任を既存のフレームワーク(それぞれNaked Objects for .NETApache Isis )に移譲する。

両新フレームワークは、多少の簡単なドメインオブジェクトのコーディングコンベンションやアノテーション(.NETの「アトリビュート」)を理解する。例えば、オブジェクトの公開メソッドは、既定で Restful Objects APIのアクションとして、利用できるが、これは、メソッドをHiddenとしてアノテートすれば、オーバーライドされる。もしオブジェクトが公開メソッドfoo([params])とまた、validateFoo([params])を定義すると、後者は、前者が実行される前に、前者に渡されるパラメータの正当性を検証するロジックを提供するものとして認識される。

両フレームワークは、またユーザーの身元と/あるいは役割を基にした細かい粒度の権限を提供する。もしあるドメインタイプに対して、ユーザーがあるプロパティ、コレクションあるいはアクションをみる権限がない場合、対応する表現で、そのオブジェクトメンバーへのリンクは、そのユーザーには決して表示されない。もしユーザーがリソースへのURLを直接構築することでアクセスしようとすると、404エラーが返される。もしユーザーがオブジェクトメンバーを見る許可を持ち、しかし修正する権限がなければ、修正しようとすると403が返される。

.NET向け Restful Objectsのソースコードは、Codeplex からダウンロードできる。あるいは、フレームワークは、NuGetパッケージとしてインストールできる。Isis用のRestful Objectsは、ソースコードとしてダウンロードするか、Maven archetypeでインストールできる。

既に Naked Objects for .NET あるいは Apache Isis使っている開発者にとっては、新フレームワークは、彼が文字通り数分で既存のドメインモデルへの RESTful APIを作成できる。しかし、我々の意図は、常に裸のオブジェクトパターンの知識が全くない、あるいは興味を持っていない開発者にアピールすることであり、我々は本当にそのような開発者が興味を持つことを希望している。

クライアント

これまで、我々の開発努力のほとんどがサーバー側にフォーカスしていた。すなわちドメインオブジェクトモデルからRestful Objects API を生成するコードである。我々はまた、そのようなAPIを利用するクライアントアプリケーションには、ある程度の限られた開発しかしてこなかった。

一つの例では、クライアントは、陳腐なwebアプリケーション( ASP.NET MVCを使って書かれている)であり、コントローラメソッドは、別のサーバーで実装されている Restful Objects APIにコールする。将来、我々は、 Restful Objectsサーバーにコールしたり、返されたJSON表現をC#やJavaで操作できるオブジェクトに変換する、小さなクライアントサイドのアプリケーションライブラリを開発したいと思っている。

我々が書いた別例のクライアントは、「1ページアプリケーション」で、ほんの数行の静的なHTMLを持つ1webページで、JQueryを使って、リッチな JavaScript関数セットがサポートされている。またしても、将来我々は、Restful Objects APIを利用する専用の、しかし JQueryを多用した、小さな JavaScriptアプリケーションライブラリを作りたいと望んでいる。あるいは、恐らく他の誰かがそれを引き継いでくれるだろう。

Restful Objects仕様の汎用的な性質が他の可能性を示唆している。RESTful API経由であらゆるドメインモデルと無修正で、 協調できるジェネリッククライアントである。我々は、既に3つの異なるオープンソースのジェネリッククライアントが開発中であることを知っている。これらは、Restful Objects webサイトに載っている。これらの全ては、1ページアプリケーションでJavaScriptで書かれ既存のライブラリを使っている。これらのジェネリッククライアント内のJavaScriptコードは、また1つ以上のカスタムクライアントを作成する基盤として使うこともできるだろう。この3つのジェネリックアプリケーションでは、ユーザーとのやり取りのスタイルが、全く違う。それらの1つで、Adam Howard 氏によって開発中のA Restful Objects Workspace (AROW)のスクリーンショットが下のものである。

(拡大するにはイメージ上でクリックする。)

反論

Restful APIを介してドメインエンティティを公開する考えは、議論を呼んでいる。ある評価者は、それは悪い考えだ、と言っている。すなわちセキュリティホールを生む。その方法で、本当の Restful APIを生成するのは不可能だ、と言う人もいる。これらの議論を詳細に見ていこう。

Rickard Öberg 氏が主張しているのは、ドメインエンティティをリソースとして見せるのは、「 HATEOASではあり得ない、それはアプリケーションの状態を見せるリソース間のリンクを生成するのに、理にかなった方法が無いからだ」、ということである。しかしこれは、明らかに真実ではない。 Restful Objectsは、エンティティをリソースとして公開し、完全に HATEOASである。そして、リンクのための非常に明らかな根拠を持っている。

Jim Webber氏が 主張しているのは、例えそれが可能でも、それは悪い考えである。なぜなら、こうすると、クライアントとサーバー間が密結合してしまうからである。 Restfulシステムでは、クライアントとサーバーは、独立して進化できるべきである、ということである。彼と他の人達の議論では、ViewModels と/あるいはユースケースを表しているオブジェクトだけを公開すべきで、それらの両方共バージョン管理されるべきで、ドメインモデルの潜在的な変化からクライアントを効果的に、隔離する。

この議論は、完全には間違っていないが、どこにでも適用できる、と我々は考える。真実は、ずっと微妙だ、と我々は信じている。この議論が当てはまる状況もあれば、当てはまらない状況も多いだろう。2つの要素を考えに入れておく必要がある。

最初の要素は、クライアントとサーバーの両方が同じグループの制御下にあるかどうかである。 Twitter やAmazonによって運営されているような、誰でもアクセスできる Restful APIなら、サーバーとクライアントは、(多くの)別個の組織によって所有されいる。この場合、ドメインエンティティを公開するのは、良いアプローチではない。しかし、 Restful Objectsは、ビューモデルと/あるいは、この場合ユースケースオブジェクトで完全に動くことができる。そして、これらのパターンは、仕様にずっと詳しく述べられている。

しかし、クライアントとサーバーの展開が同じ組織によって制御され、Restful APIを非常に多く、潜在的に使う場合がある。主に企業内で使うための、エンタープライズアプリケーションの形態である。この場合、ドメインエンティティを公開するのは、安全でないが、実際には、よい考えである。そのようなアプリケーションは、「最高の」システム(Alan Cooperによって定義されたように)のカテゴリに属し、典型的には、ユーザーに、公開にさらされる(あるいは、「一時的な」)アプリケーションにおけるよりも、ずっと広範囲なデータや機能へアクセスさせることになる。

2番目の要素は、クライアントが「特注」(とくに特定のドメインモデルで動くように書かれた)あるいは、「包括的な」(いかなるドメインモデルとも無修正で動くことができる)。これまで、Restful APIを利用する、イントラあるいは公開インターネット用の全てのクライアントのほとんどが、特注であった。なのでそれらをドメインモデルの変更から隔離する必要があった。しかし、これは、ドメインモデルの変更に自動的に反応するジェネリッククライアントでは、真実ではない。これまで、ジェネリッククライアントの可能性を考える人は、ほとんどいなかったが、それは、それらが書けるような包括的な標準がなかったからである。我々が提案するのは、ジェネリッククライアントの概念は、カスタムなクライアントよりもRESTの精神(とその文字にも)に実際のところ、ずっと合っている、ということである。結局、1レベルで、webブラウザは、restful インターフェースにはジェネリッククライアントなだけであり、ドキュメントレベルで動いている。Restful Objectは、ジェネリッククライアントの考えがもっと高いレベルの抽象層、ドメインオブジェクトモデルのレベルで動くことを可能にする。

これらの要素を2x2の表としてまとめると、以下のようになる。もしイントラアプリケーションと/あるいはジェネリッククライアントを扱うなら、 RESTful APIを介してドメインエンティティを公開するのが、安全で効果的である。もし公開のインターネットアプリケーションで、しかも特注のクライアントで開発しているなら、クライアントをサーバーの変更と切り離すために、ドメインエンティティは、ViewModelと/あるいは、ユースケースオブジェクトによって、完全にマスクされるべきである、という忠告に耳を傾ける必要がある。

                  デプロイ:
クライアントの形式:

イントラネット

インターネット

ジェネリック(汎用)

ドメインエンティティの公開は問題なし/p>

ドメインエンティティの公開は問題なし

特注

ドメインエンティティの公開は問題なし

バージョン管理されたViewModelsと/あるいはユースケースオブジェクトのみを公開する

繰り返して言う:Restful Objectは、このグリッドの全ての位置に同様に適用できる。右下隅がこれまで、最も注目を集めた、という事実は、固有の限界より特注のRestful APIを作る難しさをもっと反映したものである、と我々は考えている。別の共通の迷信-Restful APIは、小さな、密に定義された、状態遷移ダイアグラムを持つアプリケーションを作るためにのみ作られている-が人々がそのセルでのみ考えていることの更なる証拠である。

Öberg氏が更に言っているのは、ドメインエンティティを RESTful APIとして公開するのは、公開アプリケーションには上手くいかない。それは、権限の問題のためである、とResetPassword アクションへのアクセスが役割によって規制できるが、ChangePassword アクションが特定ユーザーに限らなければならない場合を例に上げている。彼が指摘しようとしている点の更に良い例は、メソッドではなく、特定のオブジェクトインスタンスへのアクセスである、と我々は考えている。これは、一般に公開されているシステムでは、共通のニーズである。例えば、ユーザーは、 ShoppingBasketにアクセスできなければならないが、URLから推測するだけでは、他の人の ShoppingBasketにアクセス出来ない。

2つのRestful Object実装のどちらも、現在インスタンスベースの権限付与を本質的にサポートしていないが、この問題に関しては、別の完全に実現性のあるソリューションが存在する。前に我々が述べたように、URLでのインスタンス識別子の形式は、 Restful Objects仕様には、規定されていない。URLのこの部分は、例えば、セッションで生成されたプライベートキーを使って、サーバーによって暗号化できる、ということである。 MyShoppingBasketを返すサービスアクションリソースを呼び出すと、オブジェクト表現を返すだろう。その「セルフ」リンクは、以下のようになる。

~/objects/baskets/xJDgTljGjyAAOmvBzIci9g

その買い物バスケットのTotal property のURLは、次のようになる。

~/objects/baskets/xJDgTljGjyAAOmvBzIci9g/properties/Total

なので、リソース識別子のパーシングは、単純であるが、他のバスケットを直接呼び出すのは、事実上不可能であろう。確かにこれはあまり美しくない。しかし、RESTは、「美しい」URLを作成する為のものではない、ことを指摘するのは、価値がある。 Tim Berners-Lee氏が強調したように、サーバーアドレスは別にして、URLは、不透明なものとして扱われるべきである。重要なのは "rel"値でる。それは、 HATEOASのポイントの一部である。

この記事で述べられている2つの Restful Objectsフレームワークの両方で、我々は、セッションキーを設定オプションとして暗号化されたインスタンス識別子にするつもりである。

結論

大規模エンタープライズシステム用の RESTful API作成することは、これまで開発用語で言えば、非常に高価な仕事であった。設計、開発、テスト、文書化において多大なリソースを必要とする。Restful Objects 仕様を実装しているフレームワークを使うことは、全仕事が非常に小さくなり、開発者は、彼らの工数を最も必要なこと、ドメインオブジェクトモデルに集中することができるようになる、事を意味する。

更に、Restful Objects 仕様によって奨励されている、リソースと表現の標準化がクライアントサイドのライブラリに対する大きな機会を与えることになり、それは、いかなるRestful Objects サーバーとも動き、また標準に従ういかなるアプリケーションで動く、完全にジェネリックなクライアントに対してさえも機会を広げることになる。

我々は、読者が Restful Objects仕様とフレームワーク実装を調べることを望む。そしてRestful Objects仕様に準拠するよう設計した新しいオープンソースフレームワークやライブラリを書くことに興味を持つ、あらゆる人からの意見を喜んで聴きたい。

参考

[1] Haywood, D, "裸のオブジェクトを使用するドメイン駆動設計s", 2009, Pragmatic Bookshelf
[2] Masse, M. "REST APIの設計ルールブック", 2011, O’Reilly
[3] Öberg, R, "REST アンチパターンとしてのドメインモデル "
[4] Pawson, R. "ケーススタディ: アイルランド政府おける大規模純粋OO ", QCon London 2011 presentation
[5] Pawson, R, "裸のオブジェクト", 2004, PhD thesis, Trinity College, Dublin.
[6] Webber, J, "Rest と DDD".

著者について

Richard Pawson 35年間ITに携わってきた  -  ヨーロッパでMicrosoft言語でプログラムを書き、実行した本当に最初の人間である、と言っている。高度なロボット、おもちゃのデザイン、技術ジャーナリズムにも携わり、Director of Researchとして14年間のComputer Sciences Corporationで働いた。 彼の 2004年の博士論文テーマは、「裸のオブジェクト」アーキテクチャー・パターン上の決定的な参照であり、それ以来、彼は裸のオブジェクト・グループのマネージング・ディレクターを務めています。彼は、イギリスの Henley-on-Thamesにある、Christopher Alexanderのパターン言語のを使用して設計した家に住んでいる。
 

Dan Haywood Javaと.NETプラットフォーム上で、ドメイン駆動設計、アジャイル開発、およびエンタープライズ・アーキテクチャに特化した、フリーランスのコンサルタント、開発者、作家であり、トレーナーでもある。彼は裸のオブジェクトのよく知られた提唱者、およびApache Isisプロジェクトの主要なコミッターだ。彼は、 Restful Objects 仕様の著者であり、DDDとオブジェクト指向に関する書籍を数冊を書いている。彼はイギリスのOxford近くに住んでいる。

この記事に星をつける

おすすめ度
スタイル

BT