26

私は現在、RESTAPIの実装に取り​​組んでいます。個々のリソース間に多数の関係があるリソースモデルがあります。

私の質問は、2つの既存のリソースをRESTfulな方法で相互にリンク（関係を確立）する方法です。

私が遭遇した解決策の1つは、LINKおよびUNLINKHTTP動詞の使用でした。APIコンシューマーは、LINKと次のURIを使用して2つのリソースをリンクできます：/ resource1 /：id1 / resource2 /：id2。

このソリューションの問題は、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で既存のリソースをリンクするためのより優れたソリューションやより洗練されたソリューションはありますか？

ありがとう

4

1 に答える 1

31

私は自分の（特注の、社内の）Webアプリを使用LINKしています。実装リファレンスとしてhttps://datatracker.ietf.org/doc/html/draft-snell-link-methodUNLINKを使用しています。

クライアントには次の3つのタイプがあることがわかりました。

  1. HTMLの要素からヒントを得GETて、をサポートするだけのもの。POST<form>
  2. GET、、、およびのみPUTをサポートするもの。これらは、CRUDおよびRPCのふりをしてRESTタイプのAPIからヒントを得ています。POSTDELETE
  3. 任意の方法を許可するもの。公式RFCとしての公開によりPATCH、WebDAVの成長と同様に、これらの量が増加しましたが、カテゴリ2のクライアントもサポートする場合がありますPATCH。

現在、クライアントを社内で開発しているため、この問題は発生しませんが、サードパーティのクライアントを許可したい場合に備えて、APIを定義する前に、問題を調査して長所と短所を検討しました。私の解決策（とにかくJavascriptなしでHTMLクライアントをサポートする必要があったので）は、フィールド（）をPOST指定してメソッドをオーバーライドし、バックエンドパームの関数を目的のHTTPメソッドの適切な関数にオフにすることでした。そうすれば、たとえば上記のクラス2にある将来のクライアントは、を使用してラップすることができます。_METHODapplication/x-www-form-urlencodedpost()PUTDELETEPATCHLINKUNLINKPOSTリクエスト。両方の長所を活用できます。それをサポートするクライアントからの豊富なメソッドでありながら、POSTトンネリングを通じて低品質のクライアントをサポートします。

于 2013-06-10T09:09:08.800 に答える