REST APIでLINKとUNLINKのHTTP動詞を使用する

Question

現在、REST APIを実装しようとしています。私は、個々のリソース間に多数の関係を持つリソース・モデルを持っています。

私の質問は、どのようにしてRESTfulな方法で2つの既存のリソースを互いに結びつける（関係を確立する）のですか？

私が見つけた解決策の1つは、LINKとUNLINK HTTP動詞の使用でした。 APIコンシューマは、LINKとURI：/ resource1 /：id1/resource2 /：id2の2つのリソースをリンクできます。

このソリューションの問題は、LINKおよびUNLINK動詞のサポートの欠如です。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.htmlまたはhttp://en.wikipedia.org/wiki/Hypertext_Transfer_Protocolには動詞が記載されておらず、主に「忘れられている」ようです。しかし、元のRFC 2068では、それが存在すると述べています。

私はこのソリューションが本当に好きです。ただし、LINK/UNLINKのサポートが不足しているため、多くのAPIコンシューマ/クライアントが解決策に対処できないことが懸念されます。これは受け入れられる解決策ですか、またはRESTful APIの既存のリソースをリンクするためのより優れた、より洗練されたソリューションがありますか？私は（会社内部、特注）ウェブアプリでLINKとUNLINKを使用

おかげ

Answer 1

。私はhttp://tools.ietf.org/html/draft-snell-link-methodを実装リファレンスとして使用しています。

私は、クライアントの3種類があることが判明：

1. のみHTMLの<form>要素から自分の手がかりを取って、GETとPOSTをサポートするものが。
2. GET,PUT,POSTおよびDELETEのみをサポートするもの。これらは、CRUDとRPC-RESTタイプのAPIに似ています。
3. どのような方法でも許可するもの。公式のRFCとしてPATCHが発行されたことで、WebDAVの成長と同様に、これらの量が増加しましたが、カテゴリー2のクライアントもPATCHをサポートすることもあります。

私たちは現在、社内でクライアントを開発しているので、この問題はありませんが、私はそれを調べてAPIを定義する前に賛否両論を検討しました。 。私の解決策（とにかくJavascriptのないHTMLクライアントをサポートする必要があったので）_METHODフィールド（application/x-www-form-urlencoded）を入力してメソッドをオーバーライドさせてから、post()の機能をバックエンドの手のひらに適切な機能HTTPメソッド。こうすることで、上記のクラス2のクライアントは、PUTとDELETEを使用できますが、POSTリクエストではPATCH,LINKとUNLINKをラップすることができます。両方の利点を最大限に引き出すことができます。それをサポートするクライアントからの豊かな方法が、POSTトンネリングを通じて低品質のクライアントをサポートします。