0

私は最初の API を構築していますが、これらのアクションはアプリケーションの中心であり、どのクライアントでも利用されるため、典型的な CRUD シナリオ以外のアクションを公開する方法で API を構築する必要があるかどうか疑問に思っています。レポート用に作成したものがありますが、ユーザーがレポートを承認または拒否できるようにする必要があるため、次のように考えています。

/api/report/id/approve
/api/report/id/deny

役に立ちます。これは、API に関して標準や慣行に違反していますか?

4

2 に答える 2

1

これらの URL を公開しても問題はありません。REST は URL について何も義務付けていません。これは、それとは関係のない一連の制約です。その一つがHATEOSです。これらのリンクを公開して、レポートのリソース表現の一部としてレポートの状態を変更すると、その制約を実装の一部として使用することになります。例えば、

<report>
  <id>2</id>
  <link url="api/report/2/approve" rel="approve"/>
  <link url="api/report/2/deny" rel="deny"/>
</report>

これにより、API がより見つけやすくなり、それが今日の Web のしくみです。もう 1 つの制約は、HTTP 動詞を正しい方法で使用する必要があることです。そのリンクへの HTTP GET は、リソースの状態を変更するため有効ではありません。HTTP GET は安全でなければならないため、リソースの状態を変更してはなりません。HTTP POST は、そのシナリオにより適しています。これらは、さまざまな制約を Web API に適用する方法のいくつかの例ですが、その設計に問題はないことを覚えておいてください。

よろしく、パブロ。

于 2013-03-12T14:54:55.277 に答える
0

APIをどのように構成するかは完全にあなた次第だと思います。おそらく「RESTful」とは呼べず、RPCに似ていますが、APIユーザーに必要な機能を提供している限り、それは本当に重要ですか？

必要なものを実現するにはいくつかの方法があり、検討できる多くの意見や「ベストプラクティス」がありますが、最終的にAPIが目的を達成する限り、どのように実装するかは問題ではありません。

于 2013-03-12T09:19:43.923 に答える