6

RESTful API を開発しています。現在、リソース固有のベンダー MIME タイプを使用してセマンティクスと意味を伝え、クライアントとサーバー間の「契約」として機能することを検討しています。

したがって、たとえば application/vnd.mycompany.person+xml は、問題のデータが個人を表す xml であることを意味します。

この API を「プライベート ラベル」にする必要があります。つまり、再販業者は、それが私の会社のサービスであることを顧客が知らなくても、顧客に API を提供できます。これが機能する方法は、私の会社が一種の一般的な URL、つまり www.example.com/api でメイン API をホストし、次に私の会社が CNAME を使用して当社のドメイン名をその URL にポイントすることです。同じ。

内部的には、すべてのリソース リンクは API ルートから相対的であるため、使用されている実際の URL が尊重されます。

ただし、任意のベンダー固有の MIME タイプを理解したりサポートしたりする必要はありません。上記の例の MIME タイプの「mycompany」の部分はどうすればよいでしょうか?

4

2 に答える 2

4

HTTP仕様には次のように書かれています：

登録されていないメディア タイプの使用は推奨されません。

以前はプラットフォームで「カスタム」メディア タイプを使用していましたが、ユーザー エージェント (ブラウザー、cURL、wget など) がコンテンツを認識しないという問題が発生しました。

カスタム メディア タイプを登録することもできますが、(A) 時間がかかります。(B) ユーザーエージェントがタイプを認識するまでに、たとえあったとしても、かなりの時間がかかります。(C) いずれにせよ、会社名が常に存在することを望まないことを示しました。

「カスタム」メディア タイプの代わりに、代わりにメディア タイプ パラメータを使用することをお勧めします。これらは、コンテンツに関する補足情報をメディア タイプに追加するための優れた方法です。

パラメータを使用すると、メディアの種類application/xml; mycompany-schema=personはapplication/xml; schema=person.

于 2011-08-02T23:27:31.253 に答える
2

RESTインターフェースを「真にRESTful」にすることで問題を「解決」するために、ベンダー固有のMIMEタイプを推奨するフレームワークとチュートリアルをいくつか見てきました。

このアプローチの問題点の 1 つは、その性質上、ハイパーメディア駆動型 REST サービスへの移行の全体的なポイントが API とサービスのモデルを変更して変更することである場合に、希望どおりに「機能させる」ためのハッキングまたはチートであることです。問題にどのようにアプローチするか。の「有効な」または許可されているが推奨されていない HTTP 値をこっそり入力することContent-Typeは、飢えたベネズエラ人にネズミは魚であり、四旬節の間に罪を犯さずに食べることができると告げるようなものです。ネズミしか食べられないのに、何か悪いことはありますか? おそらくそうではありません。しかし、それを魚のふりをすることはそれを魚にしますか? もちろん違います。コントラクト駆動型のインターフェイスが必要な場合は、RPC または SOAP を使用するか、カスタム ベンダーの MIME タイプを使用してください。しかし、仕様を指して休息だと言ってはいけません。

2 つ目の問題は、手抜きをすると、ハイパーメディア主導のインターフェイスの実際の見返りが失われることです。すぐに、ユーザー エージェントと独自のサーバーで問題が発生し、MIME タイプに慣れていないためにフープをジャンプするか、単にあきらめなければなりません。すべては、本当のRestサービスの主張でクライアントに感銘を与えたり、契約の余分な重み（明らかにいくつかのコンテキストでは価値があります）を減らすことで負荷を少し軽減したりすることがポイントではない場合に、両方の方法を持つことができると考えたからです-駆動型の相互作用であり、サービスが実際に外部クライアントと相互作用する方法を変更することでした。

最後に、ベンダー固有の MIME タイプが実際に定義済みのエンドポイントよりも優れたコントラクトをどのように強制するかについて、私は本当に不明です? このテクニックに言及しているすべてのサイトは、このオプションが存在することで安堵しているように見えます。率直に言って、技術的には「いたずら」であることを知っているように、少し独善的であり、それを使用していることを喜んでいますが、それはとても簡単で修正されていますすべての。それは何を修正しますか？personあなたの場合、受信リクエスト/コンテンツを次の場所に送信しないのはなぜですか。

POST /myRestService/people

また、他のリクエストがある場合、それは他のデータ型を対象とした別のエンドポイントに送られますか? method が必要な場合は、次のdoes_somethingいずれかを使用しませんか。

GET /myRestService/people/personID_123/does_something

また

GET /myRestService/people/does_something/personID_123

正確な文脈に応じて？

そして、私が意地悪な上に意地悪に聞こえないように、欲求不満や怒りはあなたやあなたの質問に向けられているのではなく、ベンダーのマイムタイプの「解決策」と誰もが開発した強迫観念に向けられています」ロイ・フィールディングが公式に承認し、有効な REST サービスとしてスタンプを押した」ということは、明らかに誰も実用的な公開例を提供することさえできず、必要な近道をとってすぐにそれを採用するという切迫感だけを残しており、恥と対処することができます。ショートカットが引き起こした問題を実際に修正するときに、後で指を指します。

于 2013-09-17T13:04:45.137 に答える