8

私は、既存のWCFサービスをWebAPIに変換することにより、WebAPI（および一般的にはREST）を学習しています。その過程で、CRUD以外の操作を処理するための最良の方法について混乱し始めています。これが私のサービス契約です：

[ServiceContract]
public interface IProxyHelper
{
    [OperationContract]
    List<ProxyInfo> GetUsersCurrentUserCanActAsProxyFor(int positionId, int appId);

    [OperationContract]
    void DeleteProxy(int id);

    [OperationContract]
    List<ProxyInfo> GetProxyData(int appId);

    [OperationContract]
    bool CanPositionProxy(int positionId, int appId);

    [OperationContract]
    void AddProxy(
      string userRacf,
      string proxyAsRacf,
      int userPositionId,
      int proxyPositionId,
      string requestedByRacf,
      int appId);

    [OperationContract]
    int GetPositionIdByRacf(string racf);

    [OperationContract]
    string GetRacfByPositionId(int positionId);
}

DeleteProxyやAddProxyIなどの一部のメソッドは、CRUDベースの方法論に簡単に移行できます。

質問が発生します：

GetProxyData-プロキシシステムは複数のアプリケーションで使用されています。api/Proxy/ 1を実行することはできますが、アプリケーション1のプロキシではなく、ProxyId 1を取得するためのものであるため、これは「不正行為」だと感じます。

GetUsersCurrentUserCanActAsProxyFor-これは私にとって複数のレベルで混乱しています。複数のパラメータをどのように処理する必要がありますか？また、CRUDメソッドにもうまく当てはまりません。

これは、WebAPI変換を中止する必要があることを意味しますか？そうでない場合、これらの非標準的な方法にどのように取り組む必要がありますか？

4

1 に答える 1

3

RESTfulサービスとCRUDを混同していると思います。2つは同じではありませんが、CRUDからRESTへの変換は非常に簡単です（リソースと動詞の両方に明確なマッピングがあります）。

RESTfulアーキテクチャの最大の差別化要因は、リソース指向であるということです。2つ目は、トランスポート（HTTPS）プロトコルを利用して、これらのリソースに作用することです。RESTの場合、GET、POST、PUT、およびDELETEです。

あなたの例に移ると、あなたの最大の問題は、このサービスをサポートするために使用するURIスキームを決定することであるように思われます。階層情報の場合、これは簡単なはずです。たとえば、アプリケーションプロキシ：

/application/<id>/proxies

また、現在のユーザーのユーザーは、次のプロキシとして機能できます。

/user/<id>/proxy-usersまたはあなたのスタイルに応じて/user/<id>/proxy/users

または同様のもの。あなたは関係と基礎となるリソースについて考えます。多くのURIが同じリソースを指すことができます。

ただし、@ dtbがコメントで言及しているように、URIおよび/または（あまり好ましくない）Cookieには、すべてのリクエストに必要なすべての情報が含まれていることに注意してください。ちょっとしたCurrentUserハックです。

変換を進めるにつれて、この興味深い読み物を見つけることもできます。RESTfulサービスでの非CRUD操作

于 2012-05-02T21:03:04.127 に答える