ENDPOINT LÀ GÌ

Có nên chúng ta là 1 developer mới, bạn thấy các developer lành nghề khác nói với nhau về restful. Quý Khách đo đắn restful là gì đề xuất các bạn lên google tìm kiếm “restful là gì?”. Bạn gọi tương đối nhiều nội dung bài viết rồi tuy nhiên vẫn tồn tại mung lung chưa biết khía cạnh mũi thằng restful cố kỉnh nào? Nếu nhỏng nhiều người đang Cảm Xúc như vậy, thì hãy xem thêm bài viết này của chính mình nhé.

Bạn đang xem: Endpoint là gì

Bài viết này bản thân đã trình bày số đông vẫn đề bao bọc restful api trước khi mình trình diễn cụ thể về nó, vậy cho nên các bạn hãy kiên trì phát âm nhé.


Mục lục


I. Web service là gì?II. Tìm đọc về RESTfulIII. API là gì và RESTful API là gì?

I. Web service là gì?

Website thì người nào cũng cũng biết rồi, nlỗi blog phambinch.net này chính là một trang web đó. Thế tuy nhiên web service thì khác, chưa phải người nào cũng tất cả cơ hội được nghe thấy các từ bỏ này kể từ thời điểm cơ mà Restful trnghỉ ngơi cần phổ cập.

Web service cũng là 1 trong ứng dụng web vận động tương tự như một trang web, Có nghĩa là để truy cập vào web service bạn cũng có thể mnghỉ ngơi trình coi sóc lên, gõ vào tkhô hanh liên quan url của website service đó. Tuy nhiên khác cùng với trang web – website để cho những người gọi, thì website service sinh ra khiến cho những bộ máy, hoặc những vận dụng khác hiểu.

1.1. Tại sao website service ra đời?

Câu cthị xã nhắc rằng gồm 2 anh bạn thương hiệu Quang và tên Bình đùa thân với nhau từ bỏ hồi bé dại. Lớn lên, Quang mở 1 cửa hàng trình làng việc khiến cho nhân sự IT, Bình thì mở một chủ thể đào tạo và giảng dạy nhân sự IT. Một hôm, Quang nói với Bình “ngươi ơi, công ty tao bao gồm mấy job PHP lương cao lắm, mi đặt lăng xê đến tao vào mấy khóa huấn luyện và đào tạo về PHPhường của dòng sản phẩm nhé“, Bình nghe vậy ngay tắp lự đồng ý luôn luôn, do tốt cho cả hai cơ mà. Nhưng sự việc là trang web tuyển chọn dụng của Quang cùng website huấn luyện của Bình chạy ngơi nghỉ trên 2 con hệ thống khác nhau, không có một “cây cầu” như thế nào liên kết thân nhị website này cả.

Quang suy nghĩ mang lại biện pháp sẽ cnhát “cứng” lăng xê của chính bản thân mình trong các khóa đào tạo và huấn luyện của Bình, nhưng lại Bình gạt đi. Vì chèn cứng điều này, lỡ job PHP của Quang hết hạn tuyển chọn dụng thì sao, lại gỡ xuống à? Mà một job thì ko có gì, chứ đọng 100 job thì chỉ có ckém lên cùng với gỡ xuống cũng không còn ngày. Bình bèn suy nghĩ ra cách này với bảo Quang, “mặt trang web tuyển chọn dụng của ngươi, ngươi tạo nên tao một trang riêng biệt chỉ hiển thị những job PHP mà lại ngươi ý muốn truyền bá, mặt website của tao sẽ gọi nội dung website này rồi hiển thị lên“.

Vậy là Quang tạo thành một trang web riêng rẽ mang lại Bình tại địa chỉ http://webtuyendungit.com/job-php, Lúc truy vấn vào đó đã chỉ nhận thấy câu chữ khó hiểu nhỏng sau

"jobs": < "url": "http://webtuyendungit.com/tuyen-lap-trinh-vien-php-luong-1000-dollar", "title": "Tuyển dụng thiết kế viên PHPhường lương 1000 dollar" , "url": "http://webtuyendungit.com/tuyen-lap-trinh-vien-php-khong-kinh-nghiem", "title": "Tuyển dụng lập trình sẵn viên PHPhường. không khiếp nghiệm" , >Sau kia, Bình thực hiện CURL để mang văn bản trên trang web của Quang, so sánh thành tài liệu và hiển thị ngon cơm lên website đào tạo và giảng dạy của bản thân. Giờ trên đây Quang mong mỏi biến hóa ngôn từ lăng xê thì chỉ cần biến đổi văn bản của website bên trên, hết sức thuận tiện và chủ động.

Trên chính là một ví dụ điển của web service. Lúc những áp dụng ko tương quan cho tới nhau, nhưng mà vẫn hy vọng hiệp thương dữ liệu với nhau thì người ta đang suy nghĩ tức thì cho tới việc áp dụng web service. Một website service vẫn trả về tài liệu theo một cấu trúc nào kia (XML hoặc JSON,…) để các ứng dụng khác hoàn toàn có thể gọi, so với cùng sử dụng được. Nhỏng ví dụ trên thì http://webtuyendungit.com/job-php chính là endpoint của một website service.

Web service Thành lập và hoạt động nhỏng là 1 trong điều rõ ràng, cũng chính vì ngày càng có rất nhiều hệ thống chạy nhiều căn nguyên như Facebook, Youtube,.. Thành lập. điểm sáng của những khối hệ thống chạy nhiều nền tảng gốc rễ này là luôn luôn yên cầu kỹ năng đồng nhất dữ liệu. Ví dụ bạn like một status facebook trên web, thì trên ứng dụng cũng cần được trình bày, bạn đăng một bức ảnh lên facebook từ bỏ sản phẩm điện thoại, thì trên web cũng đề nghị bắt gặp. Để làm được vấn đề đó, tín đồ ta sẽ tạo ra một bé website service, nhằm khi bạn đăng hình ảnh, lượt thích giỏi tiến hành bất kỳ hành vi gì hầu hết cần Call tới website service này mặc dầu hành vi đó được triển khai từ website tốt mobile. Mặt khác, áp dụng web với Mobile sẽ liên kết vào tầm thường web service nhằm đọc tài liệu, vì vậy sẽ bảo đảm an toàn được tài liệu là như thể nhau cho dù bên trên các nền tảng không giống nhau.

Tóm lại website service Ra đời nhằm mục đích giải quyết một vụ việc sau

Giúp các khối hệ thống không tương quan cho tới nhau vẫn rất có thể tiếp xúc được cùng với nhauĐồng bộ dữ liệu giữa những nền tảng
*
Web service ở giữa
1.2 Endpoint của website service

Mỗi URL kèm HTTP method của web service thì được Điện thoại tư vấn là một trong endpoint, nlỗi ví dụ bên trên thì mình tất cả http://webtuyendungit.com/job-phpchính là một endpoint. lúc có tác dụng một endpoint đến web service, các bạn sẽ nên quan tâm tới một số vụ việc sau:

Endpoint thực hiện cấu trúc dữ liệu như thế nào để trả về?

XML hoặc JSON là hai chắt lọc cho bạn để sử dụng làm cho dữ liệu trả về mang lại endpoint. Nhỏng ví dụ bên trên là bản thân áp dụng JSON.

URL được viết như vậy nào?

lấy ví dụ bản thân có một endpoint trả về báo cáo chi tiết của một user dựa vào ID của user được gửi lên, thì bản thân rất có thể lựa lựa chọn 1 vào nhị giải pháp viết sau (đưa sử ID của user là 1).

http://webservice.com/users?id=1http://webservice.com/users/1

Hoặc chúng ta có thể dùng một biện pháp viết không giống cũng được, nói bình thường là endpoint được viết ra sao là do chúng ta, không tồn tại luật lệ chung nào đến giải pháp viết endpoint cả.

URL áp dụng HTTPhường Method nào?

Giả sử mình chọn URL bao gồm dạng là http://webservice.com/users?id=1, nuốm HTTP.. method là gì được nhỉ? GET tuyệt POST? Câu trả lời cũng là tùy bạn, GET tuyệt POST cũng rất được, không tồn tại luật lệ như thế nào cả.

An toàn dữ liệu

Web service trao đổi tài liệu cùng với những áp dụng khác thông qua môi trường mạng. Nếu nhằm lộ những endpoint, thì khả năng cao dữ liệu trả về trong số endpoint kia cũng bị lộ. Thực tế vẫn có không ít vụ lộ lên tiếng người dùng nhưng mà nguim nhân là do những endpoint kém bảo mật thông tin.

1.3 Các các loại website service

Các endpoint của web service thừa “tự do”, tài liệu trả về, biện pháp viết url, http method đều vị bạn từ bỏ quyết định. Nhận thấy điều này ko hợp lí, nên bạn ta chỉ dẫn hai nhiều loại chuẩn cho website service nlỗi sau:

SOAP web service

Simple Object Access Protocol là một trong những dạng giao thức (cũng có thể xem như là một chuẩn). SOAPhường sử dụng XML có tác dụng cấu tạo tài liệu trả về. Tuy nhiên SOAPhường không tồn tại quy ước về kiểu cách viết url cũng tương tự http method. Nhưng bù lại, SOAPhường. lại có WS-SecuritySOAP – là 1 trong chuẩn góp bình an tài liệu, giải quyết và xử lý được vụ việc an toàn dữ liệu nhưng bản thân nhắc ở trên.

RESTful web service

REpresentational State Transfer, là một chuẩn chỉnh của website service. RESTful có thể sử dụng JSON, XML, plain text, html,.. có tác dụng cấu tạo dữ liệu trả về, gồm quy ước ví dụ về kiểu cách viết url với http method. Nhưng RESTful không cung ứng phép tắc bảo vệ đọc tin trong các endpoint như SOAP. Tuy nhiên bạn có thể thực hiện Json Web Token kết phù hợp với RESTful để giải quyết sự việc này, nên việc không có sẵn hiệ tượng bình an thông báo chưa phải là điều xứng đáng lo ngại lúc thực hiện RESTful.

SOAP vs RESTful

Ngày ni các dự án website service phần lớn (thậm chí là gần như vớ cả) phần nhiều sử dụng RESTful cố bởi thực hiện SOAP. Bởi nhỏng mình kể ra ở bên trên thì các bạn thấy RESTful bao gồm quy ước ví dụ hơn hẳn SOAPhường. Mặt không giống RESTful hoàn toàn có thể áp dụng nhiều một số loại tài liệu để trả về, trong các số ấy tất cả cả XML, vậy xét nghỉ ngơi góc độ làm sao đó nói cách khác rằng RESTful bao gồm cả SOAP cũng không không nên.

Tuy nhiên SOAP.. vẫn còn đấy được áp dụng trong vô số dự án cũ cần được bảo trì, đề nghị các bạn cơ mà tò mò được SOAPhường nữa thì càng xuất sắc.

II. Tìm gọi về RESTful

Bài viết viết về RESTful và lại quá ttách về website service. Mình trình diễn điều đó là do theo đúng trình tự thì loại chúng ta biết trước bắt buộc là web service, tiếp nối new là RESTful. Nhưng do RESTful sẽ là 1 trong từ khóa hot, đề xuất các bạn tất cả Xu thế tìm hiểu về RESTful trước cơ mà bỏ quên mất mẫu nơi bắt đầu web service.

Xem thêm: Definition Of What Do You Know (Phrase) Definition And Synonyms

Sau trên đây bắt đầu thật sự là tất cả những gì bạn muốn mày mò về RESTful nhé.

RESTful tất cả khối hệ thống phép tắc ngặt nghèo về những viết endpoint và HTTPhường. method, mình vẫn tóm tắt một vài ba nguyên lý quan trọng làm ra “tên tuổi” của RESTful nhằm các bạn tiện thể theo dõi và quan sát.

2.1 Quy tắc về HTTP. method của endpoint

Nếu là web developer, chắc chắn rằng bạn biết đến method GET cùng POST. Nhưng cùng với RESTful thì tất cả thêm một số trong những method new, kèm bí quyết thực hiện khớp ứng như sau:

GET: được thực hiện để đưa thông tin trường đoản cú máy chủ theo URI đã hỗ trợ.POST: gửi đọc tin tới máy chủ thông qua các biểu mẫu mã http (đăng kí chẳng hạn..)HEAD: kiểu như cùng với GET tuy nhiên response trả về không tồn tại body toàn thân, chỉ có headerPUT: ghi đè toàn bộ ban bố của đối tượng cùng với phần lớn gì được gửi lênPATCH: ghi đè những công bố được biến đổi của đối tượng người dùng.DELETE: xóa tài ngulặng trên server.CONNECT: tùy chỉnh thiết lập một kết nối cho tới VPS theo URI.OPTIONS: miêu tả các tùy chọn giao tiếp mang đến resource.TRACE: triển khai một bài bác chạy thử loop – baông xã theo đường dẫn đến resource.

Thực tế thì bản thân new chỉ thao tác với các method GET, POST, PUT, DELETE thôi, các method sót lại thì chưa có tác dụng bao giờ, tuy thế tương lai chắc chắn là đã chạm mặt :p.

2.2 Quy ước về resource, endpoint

Resource có nghĩa là tài ngulặng, mà lại đấy là một có mang được nhắc tới nhiều vào RESTful, bắt buộc bản thân vẫn không thay đổi keyword này mà ko Việt hóa nhé.

Resource đó là dữ liệu cơ mà chúng ta yêu cầu làm chủ, hoàn toàn có thể là customers, products, posts, images, videos… Mặt không giống, tên resource cũng sẽ mở ra vào phương pháp viết endpoint, đề xuất nếu như bạn đặt tên mang đến resource một phương pháp công nghệ, thì endpoint cũng trở thành dễ dàng nắm bắt và dễ dàng tiếp xúc hơn.

Xem ví dụ trong bảng sau nhằm hiểu rõ đâu là resource, và resource hay được viết thế nào trong mỗi endpoint

EndpointResource
http://api.example.com/usersusers
http://api.example.com/users/1/accountsaccounts
http://api.example.com/users/1/imagesimages

Dưới đây là một vài ba phép tắc để bạn tìm hiểu thêm về kiểu cách khắc tên resource làm sao cho giỏi.

Sử dụng danh từ để tại vị tên mang đến resource

RESTful tổ chức triển khai resource dưới dạng các đối tượng người sử dụng, bởi vì vậy resource bắt buộc được đặt tên dưới dạng dạng một danh từ chứ chưa hẳn một rượu cồn từ. Giả sử mình gồm một trong những resource là: users, posts, thì resource tương xứng sẽ được viết trong số endpoint như sau:

http://api.example.com/users # Liệt kê tất cả userhttp://api.example.com/users/1 # Chi tiết user tất cả ID là 1http://api.example.com/posts # Liệt kê toàn bộ posthttp://api.example.com/posts/1 # Chi tiết post bao gồm ID là 1Sử dụng đấu sượt (/) nhằm biểu hiện quan hệ phân cung cấp thân những resources

Trong thực tiễn, những resource thông thường có mối quan hệ cùng nhau. lấy ví dụ như bản thân bao gồm resource user, từng user lại có tương đối nhiều resource image. Thì minh hoàn toàn có thể thi công các endpoint nlỗi sau

http://api.example.com/users # Liệt kê toàn bộ usershttp://api.example.com/users/1 # Chi tiết user gồm ID là 1http://api.example.com/users/1/images # Liệt kê tất cả images của user gồm ID là 1Dùng vệt gạch ốp ngang (-) nhằm ngăn cách thân những cụm từ

http://api.example.com/banned-users # Tốt (1)http://api.example.com/banned_users # Không giỏi (2)http://api.example.com/bannedUsers # Không xuất sắc (3)Trong ví dụ trên, bí quyết (1) với (2) cụ thể là dễ nhìn đọc hơn những so với biện pháp (3). Một số các bạn theo nhà chương của camelcase có thể đã thấy giải pháp (3) đọc dễ hơn. Tuy nhiên trường hợp bản thân bao gồm caiTenDaiNgoangNgoang vắt này thì rõ ràng khó khăn quan sát hơn cai-ten-dai-ngoang-ngoang cố gắng này đúng không nào.

Vậy tại vì sao (1) lại giỏi rộng (2)? Nguyên nhân là dâu gạch ốp bên dưới (_) bị phụ thuộc nhiều vào font text hiển thị, trong một số trong những ngôi trường vừa lòng nó rất có thể bị đậy mất một trong những phần, hoặc bị xóa, hoặc bị chuyển thành dấu cách bên trên một số trình chuẩn y. Như vậy dễ ợt tạo ra nhầm lẫn cho tất cả những người áp dụng.

Sử dụng chữ hay đến toàn thể endpoint

http://api.example.com/banned-users # Tốt (1)HTTP://API.WEBSERVICE.COM/banned-users # Không giỏi (2)http://api.example.com/BANNED-USERS # Không xuất sắc (3)Trong từng endpoint, ngoại trừ phần giao thức và phần domain name, thì những phần còn sót lại đang minh bạch chữ hoa chữ thường xuyên. Tức là ta tất cả endpoint (1) vẫn tương tự cùng với endpoint (2), tuy nhiên endpoint (3) thì không giống trọn vẹn.

Vậy để đồng điệu và nên tránh nhầm lẫn, chúng ta đề xuất viết các endpoint bằng chữ thường xuyên.

Không áp dụng đuôi không ngừng mở rộng cho những endpoint

http://api.example.com/banned-users # tốt (1)http://api.example.com/banned-users.json # ko giỏi (2)http://api.example.com/banned-users.xml # ko giỏi (3)Đuôi không ngừng mở rộng chính là .json cùng .xml trong endpoint (2) và (3) làm việc ví dụ trên. Một số bạn cũng có thể thấy rằng điều đó là tường minc rộng, rằng lúc tôi truyền .json tức thị tôi hy vọng mang dữ liệu dạng json với tựa như với xml. Tuy nhiên làm cho những điều đó không phải là bí quyết giỏi vì:

Endpoint dài hơn nữa và chú ý có vẻ như xấu xíBạn vẫn bắt buộc bảo trì nhiều endpoint hơn

Nếu nlỗi bạn vẫn muốn endpoint rất có thể trả về không ít phong cách tài liệu khác biệt, thì bạn có thể áp dụng thuộc tính Content-Type của request header nhằm khẳng định thứ hạng dữ liệu trả về.

Sử dụng query params để thanh lọc kết quả

Giả sử mình có một endpoint /users để mang ra danh sách cục bộ users. Nhưng thực tế mình chỉ muốn lấy ra các users ngơi nghỉ nước ta. Một số bạn sẽ suy nghĩ cho cách tạo thành một endpoint nlỗi dạng hình nlỗi /users/vn nhằm xử lý thưởng thức này. Tuy nhiên chúng ta không cần thiết phải có tác dụng rứa, chúng ta có thể coi Việt Nam nhỏng một tiêu chuẩn nhằm lọc, cùng endpoint buộc phải được viết như thế này

http://api.example.com/users?country=vn # tốt. Sử dụng query params countryhttp://api.example.com/users/vn # không tốtQuý khách hàng cũng yêu cầu thực hiện query params nhằm phân trang hoặc sắp xếp hiệu quả cầm vì chưng vấn đề thi công một endpoint mới

http://api.example.com/users?page=1 # Tốthttp://api.example.com/users/pages/1 # Không tốthttp://api.example.com/users?orderBy=lachạy thử # Tốthttp://api.example.com/users/orderBy/lakiểm tra # Không tốthttp://api.example.com/users/orderBy?latest # Không tốtSử dụng HTTP method để biểu hiện CRUD

Bạn không nên biểu đạt các thao tác làm việc cùng với resource bởi bài toán chỉ ra rằng bên trên URI, cụ vào đó bạn hãy thực hiện các HTTPhường. method tương xứng.

# Liệt kê list usersHTTPhường GET http://api.example.com/users # NênHTTP. GET http://api.example.com/users/all # Không nên# Thêm một users new vào danh sáchHTTPhường POST http://api.example.com/users # NênHTTP. POST http://api.example.com/users/create # Không nênHTTP POST http://api.example.com/users/store # Không nên# Cập nhật báo cáo user tất cả ID là 1HTTPhường PUT http://api.example.com/users/1 # NênHTTP.. POST http://api.example.com/users/1/update # Không nênHTTPhường POST http://api.example.com/users/1/edit # Không nên# Xóa user tất cả ID là 1HTTP DELETE http://api.example.com/users/1 # NênHTTP POST http://api.example.com/users/1/destroy # Không nênHTTP. POST http://api.example.com/users/1/delete # Không nên2.3 Có tuyệt nhất thiết nên tuân theo 100% chuẩn RESTful không?Thực tế mình trải qua những dự án công trình sử dụng RESTful thì chưa có dự án công trình nào thực hiện được 100% chuẩn của RESTful, bởi

Đa phần những developer chỉ say đắm cần sử dụng method POST và GET mang đến đối chọi giảnMột số chủ ý nhận định rằng /users/1 cực nhọc thực hiện hơn /users?id=1

Vậy gồm độc nhất vô nhị thiết là nên chuẩn chỉnh 100% RESTful không? Câu vấn đáp là ko, chuẩn của RESTful là một cthị xã tuy vậy nó cũng bắt buộc tương xứng với việc thống tốt nhất của team, tương xứng cùng với đặc thù của dự án. Nhưng cách nhìn của chính bản thân mình là càng chuẩn chỉnh RESTful thì sẽ càng giỏi.

III. API là gì và RESTful API là gì?

3.1. API là gì?

API là viết tắt của Application Programing Interface – đồ họa xây dựng ứng dụng. Giao diện tại đây chưa phải là giao diện của ứng dụng, không hẳn là đa số khối màu sắc, bố cục của ứng dụng cơ mà mắt các bạn thấy được đâu nhé. Giao diện ở đây hệt như một chuẩn chung để kết nối vậy. lấy ví dụ như nhỏng cái ổ cắn với dòng phích gặm, mặc dù chúng rất có thể tới từ hai công ty tiếp tế khác biệt nhưng lúc cắn vào với nhau thì bọn chúng vẫn vừa khít, đó là vì chúng thuộc tuân thủ theo đúng một bối cảnh kết nối.

Vì một trong những phần mềm đựng rất nhiều lô ghích tinh vi, nên tín đồ ta search cách phân tách nhỏ nó ra thành nhiều phần, từng phần này trợ thời gọi là một trong những component. Mỗi component sẽ có được tính tự do cao, không nhiều dựa vào hoặc có thể ko phục trực thuộc vào những yếu tố không giống. Tuy là bao gồm tính độc lập cao, cơ mà để rất có thể liên kết được cùng nhau mà một trong những phần mềm hoàn chỉnh, buộc chúng vẫn buộc phải tuân thủ theo đúng một hoặc một trong những chuẩn chỉnh như thế nào đó. Thì mỗi cái chuẩn này được điện thoại tư vấn là một trong những đồ họa lập trình vận dụng – hay chính là một API.

3.2 RESTful API là gì?

RESTful API là gần như API của web service sử dụng theo chuẩn RESTful. Trước Lúc áp dụng RESTful nhằm chế tác API, tín đồ ta vẫn đưa ra những chuẩn (API) trước. ví dụ như mình biện pháp nếu như thực hiện thêm users thành công xuất sắc, thì đã đề nghị trả về header status là 200, kèm một tin nhắn gồm ngôn từ là “thành công” chẳng hạn, ai cơ mà làm sai theo phép tắc này Có nghĩa là không đúng API, với endpoint đó sẽ chỉ được coi là RESTful endpoint chứ không được coi là RESTful API.

IV. Lời kết

Kết luận lại, bài viết này mình thích chúng ta giữ một trong những ý chủ yếu sau:

RESTful chỉ là 1 chuẩn của web service, ao ước biết về RESTful thì đề nghị tìm hiểu về web service trước.RESTful ko cạnh tranh, nó chỉ là 1 trong những tập các phép tắc thôi, theo đúng quy tắc này tức là chúng ta sẽ làm được RESTful

Bạn đề nghị làm cái gi tiếp theo?

Nếu bạn đã từng thao tác làm việc với RESTful rồi, độc giả bài viết này chỉ nhằm củng cố thêm kỹ năng thì bản thân mong muốn các bạn vẫn đọc hơn về nó qua phương pháp giải thích của bản thân. Còn nếu bạn trước đó chưa từng làm việc với RESTful, hoặc đấy là lần thứ nhất bạn nghe thấy tư tưởng này, thì chúng ta nên làm một thử nghiệm website service nhỏ dại vận dụng RESTful nhằm hiểu hơn nhé, chđọng tất cả giải thích tốt cụ nào thì nội dung bài viết này của bản thân mình cũng chỉ cần kim chỉ nan nhưng thôi.

Bài viết được viết dựa trên tay nghề thao tác của bản thân và tham khảo một số trong những mối cung cấp. Xin nhận hầu hết gạch đá.

Tài liệu tđam mê khảo: https://restfulapi.net

(*) CURL: là bộ tlỗi viện được thực hiện sẽ giúp đỡ tiến hành câu hỏi gửi tài liệu trải qua nhiều giao thức khác nhau nhỏng HTTPhường, FPT…