Khanh Hoang - Kenn
Kenn is a user experience designer and front end developer who enjoys creating beautiful and usable web and mobile experiences.
HTTP là viết tắt của Hypertext Transfer Protocol. Đó là tập hợp các quy tắc chuẩn dành cho việc biểu diễn dữ liệu, application-layer giao thức cho giao tiếp giữa hệ thống phân phối, và là nền tảng của các web hiện đại. Đối với lập trình viên (web developer) thì cần phải có một sự hiểu biết mạnh mẽ của giao thức này.
Chúng ta hãy xem giao thức mạnh mẽ này qua cách nhìn của web developer. Phần này, chúng ta sẽ trang trải những điều cơ bản và phác thảo các request và response headers
Mặc dù sẽ đề cập đến một số chi tiết liên quan đến các tiêu đề, tốt nhất là thay vì tham khảo ý kiến các RFC trong pham vi (RFC 2616) . Chúng mình sẽ được trỏ đến các phần cụ thể của RFC trong suốt bài viết.
HTTP cho phép giao tiếp giữa nhiều máy chủ và khách hàng , và hỗ trợ một hỗn hợp của cấu hình mạng.
Điều này trở thành stateless protocol . Giao tiếp thường diễn ra qua giao thức TCP / IP, nhưng bất kỳ giao thông vận tải đáng tin cậy có thể được sử dụng. Cổng mặc định cho giao thức TCP / IP là 80, nhưng các cảng khác cũng có thể được sử dụng.
Gửi yêu cầu / Thực hiện yêu cầu
Tiêu đề tùy chỉnh cũng có thể được tạo ra và gửi của khách hàng.
Giao tiếp giữa một máy chủ và khách hàng xảy ra, thông qua một yêu cầu / cặp phản hồi. Các máy khách khởi tạo một thông báo yêu cầu HTTP, đó là dịch vụ thông qua một tin nhắn phản hồi HTTP trong trở lại. Ta sẽ xem xét điều này cơ bản thông điệp đôi trong phần tiếp theo.
Phiên bản hiện tại của giao thức HTTP/1.1, có thêm một vài tính năng bổ sung cho các 1,0 phiên bản trước. Điều quan trọng nhất trong số này, theo ý kiến của tôi, bao gồm kết nối liên tục, chunked chuyển-mã hóa và các tiêu đề bộ nhớ đệm hạt mịn.
Trọng tâm của truyền thông web là thông báo yêu cầu, được gửi qua Uniform Resource Locators (URL). Tôi chắc chắn bạn đã quen thuộc với các URL, nhưng vì đầy đủ, tôi sẽ đưa nó đây. Các URL có một cấu trúc đơn giản mà bao gồm của các thành phần sau:
cấu trúc URL
Giao thức thường là http, nhưng nó cũng có thể là https cho truyền thông bảo mật. Các cổng mặc định là 80, nhưng một trong có thể thể được thiết lập một cách rõ ràng, như minh họa trong các hình ảnh ở trên. Các con đường nguồn tài nguyên là con đường địa phương để các nguồn tài nguyên trên máy chủ.
URLs tiết lộ các thông tin của các máy chủ cụ thể mà chúng ta muốn giao tiếp, nhưng các hành động cần được thực hiện trên máy chủ được xác định thông qua HTTP. Tất nhiên, có một số hành động mà một khách hàng muốn các máy chủ để thực hiện. HTTP đã chuẩn hóa trên một số ít là nắm bắt được yếu tố cần thiết đó là phổ áp dụng cho tất cả các loại ứng dụng.
GET: lấy một nguồn tài nguyên hiện có. URL chứa tất cả các thông tin cần thiết các máy chủ cần phải xác định vị trí và trả lại tài nguyên.
POST: tạo ra một nguồn tài nguyên mới. POST yêu cầu thường mang một tải trọng mà xác định các dữ liệu về tài nguyên mới.
PUT: cập nhật một nguồn tài nguyên hiện có. Tải trọng có thể chứa dữ liệu cập nhật của nguồn tài liệu.
DELETE: xóa một nguồn tài nguyên hiện có.
Trên4 phương thức trên , và hầu hết các công cụ và khuôn khổ rõ ràng đưa ra những động từ yêu cầu. PUT và DELETE đôi khi được coi là phiên bản đặc biệt của động từ POST, và họ có thể được đóng gói như các yêu cầu POST với tải trọng có chứa các hành động chính xác: tạo, cập nhật hoặc xóa.
Có một số động từ được sử dụng ít hơn là HTTP cũng hỗ trợ:
HEAD: đây là tương tự như GET, nhưng không có nội dung thư. Nó được sử dụng để lấy các tiêu đề máy chủ cho một tài nguyên cụ thể, thường để kiểm tra xem tài nguyên đã thay đổi, qua thời gian.
TRACE: sử dụng để lấy các bước nhảy là một yêu cầu cần thiết để làm tròn chuyến đi từ máy chủ. Mỗi proxy trung gian hoặc gateway sẽ bơm IP hoặc tên DNS vào trường “Via”. Điều này có thể được sử dụng cho mục đích chẩn đoán.
OPTIONS: sử dụng để lấy các khả năng máy chủ. Về phía khách hàng, nó có thể được sử dụng để chỉnh sửa theo yêu cầu dựa trên những gì các máy chủ có thể được hỗ trợ
Với các URL và Verbs, khách hàng có thể bắt đầu yêu cầu đến máy chủ. Bù lại, máy chủ đáp ứng với mã trạng thái và nội dung thông báo. Các mã trạng thái là quan trọng và nói với khách hàng như thế nào để giải thích các phản ứng máy chủ. HTTP thông số xác định phạm vi số lượng nhất định cho loại hình cụ thể của phản ứng:
Tin nhắn thông tin: 1xx
Tất cả HTTP/1.1 khách hàng được yêu cầu phải chấp nhận các tiêu đề Transfer-Encoding.
Lớp này của mã số đã được giới thiệu trong HTTP/1.1 và hoàn toàn là tạm thời. Các máy chủ có thể gửi một mong đợi: 100-tiếp tục tin nhắn, nói cho khách hàng tiếp tục gửi phần còn lại của yêu cầu, hoặc bỏ qua nếu đó đã gửi nó. HTTP/1.0 khách hàng có nghĩa vụ phải bỏ qua tiêu đề này.
2xx: Successful
Điều này nói với khách hàng rằng các yêu cầu đã được xử lý thành công. Các mã phổ biến nhất là 200 OK. Đối với một yêu cầu GET, máy chủ sẽ gửi tài nguyên trong nội dung thư. Có mã số ít được sử dụng khác:
202 Chấp nhận: yêu cầu được chấp nhận nhưng có thể không bao gồm các nguồn tài nguyên trong các phản ứng. Điều này rất hữu ích để chế biến async ở phía máy chủ. Các máy chủ có thể chọn để gửi thông tin để theo dõi.
204 Không có nội dung: không có cơ quan thông báo trong các phản ứng.
205 Đặt lại Nội dung: chỉ ra cho khách hàng để thiết lập lại xem tài liệu của nó.
206 phần nội dung: chỉ ra rằng phản ứng chỉ chứa nội dung từng phần. Tiêu đề bổ sung cho phạm vi chính xác và thông tin hết nội dung.
3xx: Redirection
404 chỉ ra rằng tài nguyên là không hợp lệ và không tồn tại trên máy chủ.
Điều này đòi hỏi khách hàng phải có hành động bổ sung. Phổ biến nhất là trường hợp sử dụng là để nhảy đến một URL khác nhau để lấy các tài nguyên.
301 Moved Permanently: tài nguyên hiện tại là một URL mới.
303 Xem khác: tài nguyên được tạm thời đặt tại một URL mới. Vị trí phản ứng tiêu đề chứa URL tạm thời.
304 Không thay đổi: máy chủ đã xác định rằng tài nguyên không thay đổi và khách hàng nên sử dụng bản sao lưu trữ của nó. Điều này dựa trên thực tế là khách hàng đang gửi ETag (Enttity Tag) thông tin đó là một hash của nội dung. Các máy chủ so sánh điều này với ETag tính toán riêng của mình để kiểm tra xem có sửa đổi.
4xx: Khách hàng gặp lỗi
Các mã được sử dụng khi máy chủ nghĩ rằng khách hàng có lỗi, hoặc bằng cách yêu cầu một nguồn tài nguyên không hợp lệ hoặc thực hiện một yêu cầu xấu. Các mã phổ biến nhất trong lớp này là 404 Not Found, mà tôi nghĩ rằng tất cả mọi người sẽ nhận biết với. 404 chỉ ra rằng tài nguyên là không hợp lệ và không tồn tại trên máy chủ. Các mã khác trong nhóm này bao gồm:
400 Yêu cầu: yêu cầu đã bị thay đổi.
401 Không được quyền: yêu cầu yêu cầu xác thực. Khách hàng có thể lặp lại các yêu cầu với tiêu đề ủy quyền. Nếu khách hàng đã bao gồm tiêu đề ủy quyền, sau đó các thông tin đã sai.
403 Forbidden: máy chủ đã bị từ chối truy cập vào các tài nguyên.
405 Phương thức không được phép: động từ HTTP không hợp lệ được sử dụng trong các dòng yêu cầu, hoặc máy chủ không hỗ trợ động từ.
409 xung đột: máy chủ không thể hoàn thành yêu cầu do khách hàng đang cố gắng để sửa đổi một nguồn tài nguyên đó là mới hơn so với dấu thời gian của khách hàng. Xung đột phát sinh chủ yếu là cho các yêu cầu PUT trong hợp tác chỉnh sửa trên một tài nguyên.
5xx: Server Error
Lớp này của mã số được sử dụng để chỉ ra lỗi của máy chủ trong khi xử lý yêu cầu. Các mã lỗi thông dụng nhất là 500 Internal Server Error. Những người khác trong lớp này là:
501 Không thực hiện: máy chủ chưa hỗ trợ các chức năng được yêu cầu.
503 Dịch vụ không: điều này có thể xảy ra nếu một hệ thống nội bộ trên máy chủ đã bị lỗi hay máy chủ bị quá tải. Thông thường, các máy chủ sẽ thậm chí không đáp ứng và các yêu cầu sẽ thời gian chờ.