2013-04-16 79 views
5

Tôi đang trong quá trình phát triển dịch vụ REST cho phép người dùng xác nhận danh sách của họ dựa trên một vài thông tin xuất hiện trên hóa đơn của họ (số hóa đơn và mã hóa đơn).GET và POST trong REST Web Service

Tôi đã đọc vô số bài viết và câu hỏi về Stack Overflow về thời điểm sử dụng GET và thời điểm sử dụng POST. Nhìn chung, sự đồng thuận chung là GET nên được sử dụng cho các hoạt động idempotent và POST nên được sử dụng cho các hoạt động tạo ra một cái gì đó ở phía máy chủ. Tuy nhiên, bài viết này:

http://blog.teamtreehouse.com/the-definitive-guide-to-get-vs-post

đã gây ra cho tôi câu hỏi sử dụng GET cho kịch bản đặc biệt này, chỉ đơn giản vì thực tế mà tôi đang sử dụng những 2 mẩu thông tin như một cơ chế để xác nhận danh tính của người dùng. Tôi không cập nhật bất cứ điều gì trên máy chủ bằng cách sử dụng cuộc gọi phương thức cụ thể này, nhưng tôi cũng không nhất thiết muốn hiển thị thông tin trong URL.

Đây là dịch vụ web nội bộ và chỉ có giao diện người dùng gọi dịch vụ được hiển thị công khai, vì vậy tôi không phải lo lắng về URL hiển thị trong lịch sử trình duyệt của người dùng. Mối quan tâm duy nhất của tôi sẽ là sự kiện không chắc rằng ai đó có thể truy cập nhật ký máy chủ, trong trường hợp đó, tôi sẽ có vấn đề lớn hơn.

Tôi đang hướng tới POST vì lý do bảo mật; tuy nhiên, GET cảm thấy giống như phương pháp chính xác do thực tế là yêu cầu không có giá trị. Phương pháp được đề nghị trong trường hợp này là gì?

Trả lời

5

Độc lập với POST so với GET, tôi khuyên bạn KHÔNG nên bảo mật dựa trên đơn giản như mã zip và số hóa đơn. Tôi sẽ đặt cược vào thực tế là số hóa đơn là tuần tự (hoặc đóng), và không có nhiều mã zip xung quanh - thì đấy, tôi có toàn quyền truy cập vào danh sách của bạn.

Nếu bạn đang sử dụng phương pháp xác thực khác (thường trong tiêu đề HTTP), thì bạn tốt - không quan trọng nếu bạn có số hóa đơn nếu URL, vì vậy cũng có thể sử dụng GET.

Nếu không, thì tôi đoán POST không tệ bằng GET khi có nội dung bí mật.

+0

Cảm ơn bạn đã trả lời. Điều này xác nhận suy nghĩ của tôi về chủ đề, mặc dù POST cảm thấy sai đối với các yêu cầu không cần thiết.Mặc dù tôi đồng ý rằng có thể sử dụng phương pháp xác thực an toàn hơn, đây là yêu cầu kinh doanh và tôi cho rằng đó sẽ là chủ đề của một cuộc thảo luận khác. – Luke

0

Không thực sự thêm bất kỳ bảo mật nào trong POST so với GET. Chắc chắn, yêu cầu không có trong URL, nhưng đó là REST mà chúng tôi đang nói đến ở đây và URL sẽ không được xem bởi một con người.

+0

Chính xác. Tôi hiểu rằng không có bảo mật vốn có trong cả hai phương pháp, chỉ có thông số POST sẽ không hiển thị trong tệp nhật ký. Như bạn đã nói, tôi đoán nó không quan trọng quá nhiều khi đó là yêu cầu REST. – Luke

+0

Một số người làm cho lập luận rằng POST an toàn hơn vì máy chủ web có thể đăng nhập URL và dữ liệu bị rò rỉ đến một nơi không có nghĩa là phải. Tôi không thực sự nghĩ rằng đây là một mối quan tâm thực tế nhưng lý thuyết là ra khỏi đó. – Lee

+0

@LeeWhitney Điểm tốt. Vâng, trong mọi trường hợp bạn chắc chắn không nên gửi mật khẩu bằng GET. :-) –

0

Câu hỏi của bạn bắt đầu với một số giả định xấu. Thứ nhất, GET không chỉ dành cho bất kỳ hoạt động idempotent cũ, nó là dành cho GET tài nguyên ting từ máy chủ; nó chỉ xảy ra khi làm như vậy nên là tác dụng phụ miễn phí. Thứ hai, URL không phải là cách duy nhất để yêu cầu GET gửi dữ liệu đến máy chủ, bạn có thể sử dụng tải trọng với yêu cầu GET (ít nhất là HTTP có liên quan, một số triển khai không tốt và không hỗ trợ điều này hoặc làm cho nó khó khăn). Thứ ba, như đã chỉ ra, bạn đã chọn một số trường dữ liệu khủng khiếp để bảo mật quyền truy cập của mình. Cuối cùng, bạn đang sử dụng giao thức văn bản thuần túy theo bất kỳ cách nào, vì vậy phương thức nào thực sự cung cấp và bảo mật tốt hơn.

Bạn nên sử dụng động từ mô tả đúng nhất những gì bạn đang làm, bạn đang nhận được một số thông tin từ máy chủ, vì vậy hãy sử dụng GET. Sử dụng một số bảo mật thích hợp, chẳng hạn như mã hóa HTTPS cơ bản. Nếu bạn muốn tránh các trường này 'làm tắc nghẽn' URL, bạn có thể gửi dữ liệu trong tải trọng của yêu cầu, chẳng hạn như:

GET /listings HTTP/1.1 
Content-Type = application/json 

{ "zip"  : "IN0N0USZ1PC0D35", 
    "invoice" : "54859081145" }