3

RESTful に関するほとんどのチュートリアル、ドキュメント、記事などで、いくつかの同じ点に出くわしますが、これらの「RESTful にする理由」の点が実装されていることはめったにありません。

たとえば、私はこれを何度も読みました：

  • コンテンツ タイプ

    HTTP ヘッダーの使用

    Accept: application/json, text/plain

    URL の拡張子

    Not RESTful, URLs are not the place for Content-Type

これが実装されているのを見た API に出くわしたことはありません。私がこれまでに使用したすべての API では、常に URL の末尾に XML または JSON を追加する必要がありました。彼らはそれを間違っていますか？

  • バージョニング

    バージョン メディア タイプ

    アプリケーション/vnd.something.v1+json

    カスタム ヘッダー

    X-API バージョン: 1

    URL のバージョン

    /v1/resouce RESTful ではありません。URL にバージョンを入れることで、別のリソースを作成します

下位互換性のない機能を導入する必要がある場合は、別のリソースを作成するのが正しいことですか?

ここでも、私が使用したすべてのバージョンの API で、URL に v1、v2 を使用しています (google、imgur など)。

これらのポイントを実装しないと、API は RESTful と見なされなくなりますか?

これらの点を明確にしていただければ幸いです。

4

2 に答える 2

5

1) Accept ヘッダーの使用または形式固有の URL の使用は、どちらも RESTful システムで有効です。あなたが引用している記事は間違っています。

2) v1/resourceRESTful ではないということも正しくありません。URI を見て、その RESTful 性について結論を出すことはできません。システムを漸進的に進化させようとしている場合、URL のルートに v1 を追加することはおそらく良いことではありません。実際には、まったく新しい URL 空間を宣言し、古いものを廃止します。それはかなり劇的です。RESTFul システムは、システムの漸進的かつ進化的な変更を可能にしようと試みます。そうすること/resource/v2は、実際にはその目標にはるかに適合します。

ここで起こっている不幸な現象は、REST について学んでいる多くの開発者が、REST を実行していると主張する大多数のシステムが、実際には REST の制約に準拠していないことに気付くことです。そのため、彼らはすぐに、RESTful とは何かを皆に伝えようとする熱意を育みます。これらの人々の多くは、まだ制約を完全に理解しておらず、存在しない新しい制約をでっち上げてしまいます。「RESTFul URL」の誤謬は古典的です。「POST はリソースを作成する必要があります」は、もう 1 つの一般的なものです。

REST を学んでいる人への私のガイダンスは、何かが RESTful ではないと言われたら、それが違反している制約と、その制約を無視した場合の実際的な影響を尋ねることです。答えられない場合は、丁寧に無視してください。

于 2012-04-25T12:34:41.013 に答える
1

REST の真の定義は明らかに、2002 年に Roy Fielding によって書かれた博士論文にあります。RESTful と自称する API はすべて、Fielding によって指定されたガイドラインに従っていますか? 答えはノーだ。REST の定義は、SOAP を使用しないものすべてを意味するように簡略化されています。RESTful とは何かについてはあまり心配せず、グッド プラクティスとは何かについてもっと心配します。リクエストのヘッダーでコンテンツ タイプを指定することをお勧めします。また、API をバージョン管理することもお勧めします。API のベスト プラクティスに関する情報は、この分野で豊富な経験を持つApigeeの担当者から入手できます。RESTful API の設計に関するウェビナーをチェックしてください。そこでは、あなたがプラグマティストか RESTafarian かを尋ねられます。

于 2012-04-25T12:49:16.607 に答える