HALを使用して HATEOAS を容易にする注文管理用の RESTful API があるとします。
GET /orders/2
{
"_links": {
"self": "/orders/2",
"items": "/orders/2/items"
},
"subtotal": 30.0,
"shipped": false
}
インターフェイスのセットを使用してクライアント (アプリケーション) を作成したいので、これらのインターフェイスの実装が DI-d ファクトリなどによって DI-d/ビルドされていると仮定すると、気にする必要はありません (気にする必要はありません)。それらが私の RESTful API によって支えられていること。例として (疑似 C#/Java):
public interface Order {
public void addItem(Item item);
public float getSubtotal();
public boolean getShipped();
}
Order order = ...;
Item item = ...;
order.addItem(item);
...(order.getSubtotal())...;
私の質問は次のとおりです: API からOrder
/インターフェースの実装を生成することは意味がありますか? Item
これは、WSDL をエクスポートする C#/Web サービスで提供されるものと同様の方法を意味します。
API のスキーマをトラバースするための HATEOAS API を効果的に使用できるように、 andOPTIONS
などのリソースを実装することを考えていました。/orders
/orders/{id}
GET /orders/* (I'd need a suitable wildcard of course)
{
"_links": {
"addItem": {
"href": "/orders/{id}/items",
"templated": true,
"type": "method"
}
}
}
もちろん、_links
オブジェクトのこの部分を任意のリソース (/orders/2
たとえば ) で返すようにすることもできますが、それでは静的コード生成が妨げられます。
特定のリンクが提供された場合、関連するアクションが利用可能/実行されるべきであるという事実をカプセル化する賢明な方法があるかどうか疑問に思っています。
注: 念のために言っておきますが、私は実際には JavaScript (特に AngularJS) で作業しています。ただし、一連の概念的なインターフェイス/コントラクトを使用してアプリケーションを作成したいと考えています。