2

RESTAPIを使用してWebサービスを構築することに興味があります。私はHATEOASについて読んでいますが、多くの例では、人間がWebをサーフィンするときに行うことと比較することで概念を説明しています。これは私に考えさせられます、それが人間と機械の両方で簡単に使用できるような方法でREST APIを構築してみませんか？

たとえば、ウィジェットの内部モデルがあり、このウィジェットには部品番号や価格などのプロパティがあります。マシンがウィジェットのリストを要求すると、JSON表現を返すことができます。

{
    widgets: [
        {
            id: 1,
            part_number: "FOO123",
            price: 100,
            url: "/widget/1"
        },
        {
            id: 2,
            part_number: "FOO456",
            price: 150,
            url: "/widget/2"
        },
        {
            id: 3,
            part_number: "FOO789",
            price: 200,
            url: "/widget/3"
        },
        ...
    ]
}

人間が自分のWebブラウザーを介して同じリストを要求すると、同じ内部モデルを取得し、それに異なるビューを適用してHTML応答を生成できるはずです。（もちろん、ヘッダーやフッターなどの他のページ要素でHTML応答を装飾します）

これは賢明なデザインですか？なぜまたはなぜそうではないのですか？実際にやっている人気サイトはありますか？

私が目にする最大の欠点は、ユーザーがリソースを削除する明確な方法がないことです。私のユースケースでは、ユーザーがリソースを変更または削除できるようにするつもりはないので、これは大したことではありませんが、一般的にはどのように処理できますか？

4

4 に答える 4

6

@mehaase

まず、登録済みのJSONハイパーメディア形式の1つを使用することをお勧めします。

それらはすべて、セマンティックリンク関係を持つリンクを作成するための明示的なセマンティクスを提供します。

たとえば、Collection（.next）+ JSONを使用すると、ウィジェットを次のように表現できます。

{"collection": {
  "version": 1.0,

  "items": [{
    "href": "/widget/1",

    "data": [{
      "name": "id",
      "value": 1,
      "prompt": "ID"
    }, {
      "name": "part_number",
      "value": "FOO123",
      "prompt": "Part number"
    }, {
      "name": "price",
      "value": 100,
      "prompt": "Price"
    }],

    "links": [{
      "rel": "self",
      "href": "http://...",
    }, {
      "rel": "edit",
      "href": "http://..."
    }]

  }]
}}

これにはいくつかの利点があります。

  • リンクを指定するための車輪の再発明は必要ありません
  • 登録されているすべてのリンク関係タイプを自由に使用できます：http： //www.iana.org/assignments/link-relations/link-relations.xml
  • データ構造に基づいて、前述の形式のコレクション/アイテムのセマンティクスを簡単に使用できます
  • 必要に応じて、入力フォームについても説明できます

例からわかるように、HTML（または他の形式）に変換するための十分な情報があります。

私が目にする最大の欠点は、ユーザーがリソースを削除する明確な方法がないことです。私のユースケースでは、ユーザーがリソースを変更または削除できるようにするつもりはないので、これは大したことではありませんが、一般的にはどのように処理できますか？

この読み取り「編集」リンク関係仕様の場合、リソースを削除できることを意味します。

于 2012-06-01T15:49:16.337 に答える
4

できることはいくつかありますが、最初の前提は、最新の「汎用」Webブラウザーが本当に不格好なRESTクライアントであるということです。

インタラクションのほとんどがJavaScriptによって保護および管理されている場合、リンク、フォーム、戻るボタンだけでなく、JSで生成されたリクエストに依存している、いわば「リッチクライアント」を作成すると、より良い結果が得られます。 RESTクライアント。

フォームとリンクの一般的なブラウザエクスペリエンスに固執している場合は、POSTをオーバーロードすることで、他のHTTP動詞の欠如を回避できます。あなたは仲介者によるいくつかの保証を失います。DELETEはべき等であり、POSTはそうではなく、これには影響がありますが、壊滅的ではなく、回避する必要があります。POSTを使用してべき等なことを行うことはできますが、仲介者はそれらがべき等であることを「認識」しないため、そのべき等を想定することはできません。

「POSTuberalles」に行く必要がある場合は、マシンクライアントを同じAPIに制限するか、並列サービス（POSTの愚かなクライアントで使用されるサービスと全範囲を利用できる他のサービス）を提供します。 。

とはいえ、XMLベースのハイパーメディア形式を選択した場合、できることはXMLペイロードにXSL変換を追加することです。ブラウザはペイロードでXSLを実行し、好きなだけきれいなページ（ヘッダー、フッター、馬を窒息させるのに十分なJSなど）を作成しますが、マシンはその側面を無視し、指定されたデータのみに焦点を合わせます。

その点であなたに「両方の長所」を与えます。

于 2012-06-01T17:05:56.533 に答える
1

いつでもRESTAPIを構築してから、その周りに独自の人間に優しいWebアプリを構築できます。すぐに使用できる機能と開発者向けの拡張可能なシステムがあるため、これは一般的な方法です。

于 2012-06-01T15:45:30.050 に答える
0

RDFaでHTMLを使用するだけでこれを行うことができます。したがって、人間はHTMLを読み取ることができ、マシンはRDFa注釈を読み取ることができます。リンクに注釈を付けるにはhydraのようなREST語彙が必要であり、コンテンツに注釈を付けるにはschema.orgのような他の語彙が必要です。

人間用のHTMLやマシン用のJSON-LDなど、さまざまなタイプのクライアントにさまざまなメディアタイプを使用する別のオプション。

于 2013-12-02T14:30:25.553 に答える