2012-12-26 27 views
13

REST đang sử dụng các tính năng hiện tại của Web và áp dụng một số nguyên tắc trên trang web để làm cho nó hiệu quả hơn. Nó sử dụng các động từ HTTP tiêu chuẩn để giao tiếp và nhận trợ giúp về bản chất không trạng thái của nó.Tôi có thể sử dụng TCP trong dịch vụ RESTful không?

Tuy nhiên, có thể dịch vụ REST sử dụng giao thức TCP để giao tiếp không? Nếu có, thì nó sẽ vi phạm nguyên tắc của nó?

+2

Tôi chưa bao giờ nghe nói rằng "hiệu trưởng" của REST là nhằm mục đích làm cho nó hiệu quả hơn. –

Trả lời

18

HTTP là giao thức dựa trên TCP/IP. Vì vậy, khi bạn sử dụng REST, bạn đã sử dụng TCP để giao tiếp. Nhưng nếu bạn muốn sử dụng REST trên socket TCP thuần túy, không có HTTP, thì không, điều này không có ý nghĩa vì REST dựa trên các động từ HTTP và các tiêu đề. Những khái niệm đó chỉ tồn tại trong giao thức HTTP.

+0

Nhưng WCF được phát triển theo cách mà bằng cách thay đổi chỉ các ràng buộc cùng một dịch vụ có thể làm việc với HTTP, TCP, IPC hoặc giao thức khác, vì vậy có nghĩa là tính năng WCF này không được hỗ trợ trên Rest WCF Service. – funsukvangdu

+4

Bạn chỉ có thể sử dụng REST với HTTP. –

+0

Có hoàn toàn đúng là REST phụ thuộc vào HTTP không? – MBen

0

Bạn không thể sử dụng các ràng buộc khác ngoại trừ Http cho các dịch vụ dựa trên phần còn lại. Đó là do Rest là một phong cách kiến ​​trúc dựa trên nguyên lý nhất định. Một trong những nguyên tắc này là để giúp đỡ của giao thức không quốc tịch của web đó là http, cũng nó muốn Http từ như Get, Port, Put và Delete để sử dụng mà không có sẵn tại TCP Giao thức

1

Như Darin đã answered, HTTP là một giao thức TCP với một số chi phí mà chính xác là những gì được sử dụng trong định nghĩa RESTful. Vì vậy, không, bạn không thể xóa chi phí HTTP.

Tôi tin rằng câu hỏi của bạn "Tôi có thể sử dụng giao thức TCP cho một ứng dụng RESTful nhanh hơn?" có liên quan với câu hỏi "Tại sao rất nhiều trang web được sử dụng REST nếu HTTP là chậm hơn so với TCP tinh khiết?".

Sự thật là: HTTP là thực sự chậm hơn so với các hình thức TCP nhị phân thuần túy, nhưng trong nhất ứng dụng, người dùng của bạn sẽ không nhận thấy sự khác biệt vì chi phí thực sự là rất nhỏ và thường khách hàng sẽ làm cho chỉ một vài yêu cầu mỗi phút.

Ví dụ: GET /posts?userId=5

Nếu yêu cầu này phải mất hơn một vài mili giây để hoàn thành, thì vấn đề không phải là trong giao thức HTTP. Vấn đề hiệu suất có liên quan đến độ trễ mạng, với mã phía máy chủ của bạn và cách bạn lấy dữ liệu từ cơ sở dữ liệu của mình.

Mặt khác, nếu mã khách hàng của bạn đang tạo hàng nghìn yêu cầu mỗi phút, vì vậy, một khách hàng duy nhất này sẽ nhận thấy một vấn đề về hiệu suất liên quan đến chi phí HTTP. Trong trường hợp này, có thể bạn có thể thực hiện nhiều thao tác trong một thao tác đơn lẻ và giảm lượng yêu cầu mạng.

Nếu một khách hàng thực sự cần thực hiện hàng nghìn yêu cầu mỗi phút, bạn có thể nghĩ đến việc tránh REST và bắt đầu tìm cách tiếp cận khác. Chỉ cần nhớ rằng SOAP có thể sử dụng một ràng buộc TCP, nhưng các yêu cầu cũng có chi phí để phân tích cú pháp XML. Ngoài ra, SOAP là stateful và HTTP là không trạng thái. Một cách tiếp cận trạng thái tồi tệ hơn cho khả năng mở rộng.

3

Góc hơi khác:

1. Không sử dụng WCF để tạo các dịch vụ dựa trên REST. Sử dụng Asp.Net WebAPI.

2. Chỉ cần cho vui: nếu bạn muốn sử dụng WCF TCP bindings với 'REST' nguyên tắc trong tâm trí, có lẽ bạn có thể tạo ra một API không trạng thái dựa trên 'tài nguyên' thay vì một RPC điển hình như một.

[ServiceContract] 
interface RestApi 
{ 
    Result Get(string id); 
    Result Post(string id, Resource resource); 
    Result Put(string id, Resource resource); 
    void Delete(string id); 
} 

Bằng cách đó bạn sẽ không phải xác định hợp đồng khác cho mọi dịch vụ và chỉ điều chỉnh tài nguyên của mình cho các tương tác khác nhau.

LƯU Ý: Tôi không đề nghị bất kỳ ai làm điều này: nó đang phát minh lại bánh xe. Sử dụng WebAPI nếu bạn muốn REST.

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