0

私がRESTで読んだことは、REST応答を返すときにIDではなく説明を常に使用しているようです。例えば：

<order>
    <orderstatus>
        open
     </orderstatus>
     .....
     .....
</order>

ID の使用に何か問題がありますか? たとえば、「open」が {1} の場合

<order>
     <orderstatus>
        1
     </orderstatus>
     .......
     ........
</order>

説明を取得するためのコード テーブルの別の URL があると思います。次のようなもの: http://baseurl/codetables/orderstatus&http://baseurl/codetables/orderstatus/{id}

4

2 に答える 2

1

通常、ID は、データベースが正規化された状態を維持し、一意性を提供するためだけのものです。そのため、ID を公開する REST API が必要になることはほとんどありません。そのため、この必要性が生じる理由について設計を再確認することをお勧めします。

とはいえ、ユースケースが異なり、ID が実際には外部にある必要があるものである場合、REST API が ID を返すことに問題はないと思います。

于 2012-05-26T14:11:43.267 に答える
0

リソースの状態は、例で示した両方の XML ペイロードで正確に同じ程度に記述または表現されています。「開く」という単語が付いているものは、数字の「1」に比べて人間の目に優しいため、説明が少なくて済みます。それでも、一方が他方よりも RESTful であるとは思いません。おそらく、「オープン」という言葉でさえ十分に説明されるべきだからです。消費者は、オープン状態が実際に何を意味するのかを理解できる必要があります。その時点から可能な状態遷移は何ですか? などなど

2 つ目 http://baseurl/codetables/orderstatus/{id}はhttp://baseurl/codetables/orderstatus/open 、REST URL の観点から見た場合とあまり変わらないということです。しかし、考慮すべきもう 1 つの点は、属性参照を REST リソースとして表現する必要があるかということです。メリットは何ですか？私には、WSDL の世界におけるスキーマ定義に相当するように思えます。

于 2014-06-03T10:42:19.947 に答える