2012-05-02 35 views
7

Tôi đang tìm hiểu WebAPI (và REST nói chung) bằng cách chuyển đổi dịch vụ WCF hiện có thành WebAPI. Trong quá trình này, tôi trở nên bối rối như cách tốt nhất để xử lý các hoạt động phi CRUD. Đây là Hợp đồng dịch vụ của tôi:Hoạt động phi CRUD trong dịch vụ RESTful (WebAPI)

[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); 
} 

Một số phương pháp, như DeleteProxy và AddProxy tôi có thể dễ dàng chuyển sang phương pháp dựa trên CRUD.

Những câu hỏi nảy sinh xung quanh:

GetProxyData - Hệ thống proxy được sử dụng bởi nhiều ứng dụng, và mặc dù tôi có thể làm api/Proxy/1, tôi cảm thấy đó là "lừa dối" bởi vì đó nên để nhận ProxyId 1, không phải là proxy cho ứng dụng 1.

GetUsersCurrentUserCanActAsProxyFor - Điều này gây nhầm lẫn với nhiều cấp độ đối với tôi. Tôi nên xử lý nhiều thông số như thế nào? Và nó cũng không rơi vào phương pháp CRUD.

Điều này có nghĩa là tôi nên từ bỏ chuyển đổi WebAPI? Nếu không, tôi nên giải quyết những phương pháp phi tiêu chuẩn như thế nào?

+1

'GetUsersCurrentUserCanActAsProxyFor' không RESTful, bởi vì một yêu cầu cần kiến ​​thức tiềm ẩn của người sử dụng "hiện tại". Thay đổi nó thành 'GetUsersUserCanActAsProxyFor (chuỗi người dùng, int positionId, int appId)' và trả về trạng thái 401 nếu người yêu cầu không được phép xem thông tin cho người dùng khác ngoài chính mình. Cả hai 'GetUsersUserCanActAsProxyFor' và' GetProxyData' dường như phù hợp với các yêu cầu cho GET (an toàn, idempotent), do đó, nó chỉ là vấn đề hương vị cách bạn thiết kế các URI của bạn. – dtb

+0

Cảm ơn bạn đã làm rõ, dtb. Tôi nghĩ tôi sẽ đọc nhiều hơn về mô hình REST trước khi tôi tiếp tục cố gắng chuyển đổi WCF một cách mù quáng thành WebAPI. –

Trả lời

3

Tôi nghĩ bạn đang nhầm lẫn giữa các dịch vụ RESTful với CRUD. Cả hai đều không giống nhau, mặc dù điểm rõ ràng là việc chuyển đổi CRUD thành REST khá đơn giản (cả tài nguyên và động từ đều có ánh xạ rõ ràng).

Điểm khác biệt lớn nhất của kiến ​​trúc RESTful là nó được định hướng tài nguyên. Thứ hai là bạn tận dụng giao thức truyền tải (HTTP) để thực hiện các tài nguyên đó - trong trường hợp REST là GET, POST, PUT và DELETE.

Chuyển sang ví dụ của bạn, có vẻ như sự cố lớn nhất của bạn là quyết định về lược đồ URI để sử dụng để hỗ trợ dịch vụ này. Tôi có thể gợi ý rằng đối với thông tin phân cấp thì điều này sẽ đơn giản. Ví dụ, ứng dụng proxy:

/application/<id>/proxies

Và người sử dụng người dùng hiện có thể đóng vai trò là đại diện cho:

/user/<id>/proxy-users hoặc tùy thuộc vào phong cách của bạn /user/<id>/proxy/users

Hoặc một cái gì đó tương tự. Bạn nghĩ về mối quan hệ và tài nguyên cơ bản. Nhiều URI có thể trỏ đến cùng một tài nguyên.

Lưu ý rằng mặc dù @dtb đề cập trong nhận xét của ông, cookie URI và/hoặc (ít tốt hơn) chứa tất cả thông tin cần thiết trong mọi yêu cầu. Vì vậy, CurrentUser là một chút của một hack.

Bạn cũng có thể tìm đọc thú vị này khi bạn tiến bộ trong chuyển đổi của bạn: Non-CRUD operations in a RESTful service

+0

Cảm ơn, yamen, điều này rất hữu ích. Vì vậy, thay vì có một điểm cuối "Proxy Service", tôi nên có ba: ApplicationProxies, UserProxies và ProxyCrud? –

+0

Không có dịch vụ nào là tốt, chỉ cần đi đến đó một cách thích hợp. – yamen

Các vấn đề liên quan