Restful web service là gì

Home Blogs restful web service là gì

Có buộc phải chúng ta là một trong những developer new, bạn thấy những developer tay nghề cao khác nói với nhau về restful. quý khách hàng đo đắn restful là gì bắt buộc chúng ta 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 nhưng vẫn còn đấy mông lung chưa biết đến phương diện mũi thằng restful cố kỉnh nào? Nếu nlỗi ai đang Cảm Xúc như vậy, thì hãy tham khảo bài viết này của chính bản thân mình nhé.

Bạn đang xem: Restful web service là gì

Bài viết này bản thân sẽ trình diễn rất nhiều vẫn đề bao phủ restful api trước lúc mình trình bày cụ thể về nó, thế nên bạn hãy kiên trì đọc nhé.


I. Web service là gì?

Website thì ai ai cũng cũng biết rồi, nlỗi blog jualkaosmuslim.com này chính là một trang web kia. Thế nhưng web service thì không giống, chưa phải ai ai cũng bao gồm cơ hội được nghe thấy cụm trường đoản cú này kể từ lúc mà lại Restful trngơi nghỉ đề xuất phổ biến.

Web service cũng là một ứng dụng web vận động tựa như như một trang web, tức là nhằm truy cập vào website service chúng ta cũng có thể mnghỉ ngơi trình chú ý lên, gõ vào tkhô hanh tác động url của website service đó. Tuy nhiên không giống cùng với trang web – web nhằm cho người hiểu, thì website service xuất hiện để cho những cỗ máy, hoặc những áp dụng không giống phát âm.

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

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

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

Vậy là Quang chế tác một trang web riêng mang đến Bình tại địa chỉ http://webtuyendungit.com/job-php, khi truy cập vào đây đã chỉ nhận thấy nội dung cạnh tranh gọi như sau

"jobs": < "url": "http://webtuyendungit.com/tuyen-lap-trinh-vien-php-luong-1000-dollar", "title": "Tuyển dụng lập trình viên PHP 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 PHP.. không tởm nghiệm" , >Sau kia, Bình áp dụng CURL để mang ngôn từ bên trên trang web của Quang, phân tích thành dữ liệu cùng hiển thị ngon lành lên trang web đào tạo và giảng dạy của bản thân mình. Giờ phía trên Quang ao ước biến hóa ngôn từ quảng bá thì chỉ cần biến đổi văn bản của trang web trên, khôn xiết tiện lợi cùng chủ động.

Trên chính là một ví dụ điển của website service. khi những ứng dụng ko liên quan cho tới nhau, tuy thế vẫn mong mỏi dàn xếp tài liệu với nhau thì người ta đang nghĩ ngay cho tới vấn đề sử dụng web service. Một web service đã trả về dữ liệu theo một cấu tạo làm sao đó (XML hoặc JSON,…) nhằm những áp dụng khác có thể hiểu, đối chiếu và thực hiện được. Nlỗi ví dụ trên thì http://webtuyendungit.com/job-php chính là endpoint của một web service.

Web service thành lập và hoạt động nlỗi là 1 điều hiển nhiên, bởi vì ngày dần có không ít khối hệ thống chạy đa căn nguyên như Facebook, Youtube,.. Thành lập. Đặc điểm của những khối hệ thống chạy đa nền tảng gốc rễ này là luôn đòi hỏi kỹ năng đồng hóa dữ liệu. ví dụ như bạn lượt thích một status facebook bên trên web, thì trên app cũng bắt buộc được diễn đạt, các bạn đăng một tấm hình lên facebook trường đoản cú Mobile, thì bên trên web cũng yêu cầu nhìn thấy. Để có tác dụng được vấn đề đó, người ta sẽ tạo nên ra một nhỏ web service, để khi chúng ta đăng hình họa, like giỏi tiến hành ngẫu nhiên hành động gì phần lớn cần Gọi cho tới website service này mặc dù hành động này được tiến hành trường đoản cú website hay điện thoại. Mặt không giống, vận dụng web với sản phẩm điện thoại vẫn kết nối vào tầm thường web service nhằm hiểu dữ liệu, bởi vì vậy sẽ bảo đảm được dữ liệu là tương tự nhau cho dù trên các căn cơ không giống nhau.

Tóm lại website service thành lập nhằm mục tiêu giải quyết và xử lý một sự việc sau

Giúp những khối hệ thống ko liên quan cho tới nhau vẫn rất có thể tiếp xúc được 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 web service

Mỗi URL kèm HTTP method của web service thì được gọi là 1 trong endpoint, nlỗi ví dụ trên thì mình gồm http://webtuyendungit.com/job-phpchính là một endpoint. Khi làm một endpoint mang đến web service, các bạn sẽ buộc phải quyên tâm cho tới một số trong những vấn đề sau:

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

XML hoặc JSON là hai chắt lọc cho chính mình để thực hiện có tác dụng dữ liệu trả về cho endpoint. Nlỗi ví dụ trên là bản thân áp dụng JSON.

URL được viết như thế nào?

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

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

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

URL sử dụng HTTP Method nào?

Giả sử bản thân lựa chọn URL tất cả dạng là http://webservice.com/users?id=1, thay HTTPhường. method là gì được nhỉ? GET giỏi POST? Câu trả lời cũng là tùy các bạn, GET hay POST cũng được, không tồn tại phép tắc như thế nào cả.

An toàn dữ liệu

Web service đàm phán dữ liệu với những vận dụng không giống trải qua môi trường thiên nhiên mạng. Nếu để lộ các endpoint, thì năng lực cao dữ liệu trả về trong số endpoint đó cũng trở nên lộ. Thực tế đang có tương đối nhiều vụ lộ công bố người dùng mà lại nguyên nhân là do các endpoint kém bảo mật.

1.3 Các loại web service

Các endpoint của website service thừa “tự do”, dữ liệu trả về, bí quyết viết url, http method hồ hết bởi vì các bạn trường đoản cú ra quyết định. Nhận thấy điều đó không phải chăng, phải tín đồ ta chỉ dẫn nhì các loại chuẩn chỉnh mang lại web service nhỏng sau:

SOAPhường. web service

Simple Object Access Protocol là một trong những dạng giao thức (cũng rất có thể coi là một chuẩn). SOAP.. sử dụng XML làm cho cấu trúc dữ liệu trả về. Tuy nhiên SOAPhường. không có quy ước về cách viết url cũng giống như http method. Nhưng bù lại, SOAPhường. lại sở hữu WS-Security SOAP – là 1 trong những chuẩn chỉnh giúp an toàn dữ liệu, giải quyết được vụ việc bình an dữ liệu mà mình nhắc ở bên trên.

RESTful web service

REpresentational State Transfer, là 1 trong chuẩn chỉnh của website service. RESTful rất có thể thực hiện JSON, XML, plain text, html,.. có tác dụng cấu tạo tài liệu trả về, tất cả quy ước cụ thể về phong thái viết url và http method. Nhưng RESTful không cung ứng vẻ ngoài đảm bảo công bố trong các endpoint nlỗi SOAPhường. Tuy nhiên bạn cũng có thể áp dụng Json Web Token kết hợp với RESTful để giải quyết và xử lý vấn đề này, nên việc không tồn tại sẵn cách thức an ninh thông tin chưa hẳn là điều đáng khiếp sợ Lúc thực hiện RESTful.

SOAP vs RESTful

Ngày nay những dự án website service đa số (thậm chí còn gần như là tất cả) số đông sử dụng RESTful nỗ lực vì chưng thực hiện SOAPhường. Bởi như bản thân nhắc ra ở bên trên thì bạn thấy RESTful tất cả quy ước rõ ràng hơn nhiều SOAP. Mặt không giống RESTful hoàn toàn có thể áp dụng những một số loại tài liệu nhằm trả về, trong các số ấy tất cả cả XML, vậy xét sinh hoạt khía cạnh như thế nào kia nói theo một cách khác rằng RESTful bao gồm cả SOAP.. cũng ko không đúng.

Tuy nhiên SOAP vẫn còn đó được áp dụng trong nhiều dự án cũ cần được gia hạn, buộc phải các bạn mà khám phá được SOAPhường nữa thì sẽ càng tốt.

II. Tìm phát âm về RESTful

Bài viết viết về RESTful và lại vượt ttách về website service. Mình trình bày điều này là vì theo đúng trình tự thì dòng họ biết trước đề nghị là website service, sau đó bắt đầu là RESTful. Nhưng bởi vì RESTful vẫn là 1 trong những từ khóa hot, bắt buộc các bạn bao gồm Xu thế khám phá về RESTful trước mà quên mất mất cái cội website service.

Xem thêm: Cách Lên Đồ Shyvana Tank - Cách Chơi Shyvana, Cách Lên Đồ Của Long Nữ

Sau đây new thiệt sự là các thứ bạn có nhu cầu tìm hiểu về RESTful nhé.

RESTful có khối hệ thống luật lệ nghiêm ngặt về các viết endpoint với HTTP. method, bản thân đã bắt tắt một vài phép tắc đặc biệt quan trọng làm nên “tên tuổi” của RESTful để bạn tiện quan sát và theo dõi.

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

Nếu là website developer, chắc chắn rằng bạn nghe biết method GET cùng POST. Nhưng cùng với RESTful thì gồm thêm một trong những method mới, kèm bí quyết thực hiện tương ứng như sau:

GET: được thực hiện để lấy công bố trường đoản cú máy chủ theo URI đang cung ứng.POST: gửi báo cáo cho tới máy chủ trải qua các biểu chủng loại http (đăng kí chẳng hạn..)HEAD: như là cùng với GET nhưng lại response trả về không tồn tại body toàn thân, chỉ có headerPUT: ghi đtrần tất cả thông tin của đối tượng với đầy đủ gì được gửi lênPATCH: ghi đtrằn các báo cáo được thay đổi của đối tượng người sử dụng.DELETE: xóa tài nguyên ổn bên trên hệ thống.CONNECT: tùy chỉnh cấu hình một liên kết cho tới VPS theo URI.OPTIONS: diễn tả các tùy lựa chọn tiếp xúc đến resource.TRACE: thực hiện một bài xích demo loop – back theo băng thông mang đến resource.

Thực tế thì bản thân new chỉ thao tác làm việc cùng với những method GET, POST, PUT, DELETE thôi, các method còn sót lại thì chưa làm cho bao giờ, cơ mà tương lai chắc hẳn rằng đã chạm mặt :p.

2.2 Quy ước về resource, endpoint

Resource tức là tài nguim, cơ mà đấy là một định nghĩa được nhắc đến nhiều trong RESTful, nên mình đang không thay đổi từ khóa này nhưng không Việt hóa nhé.

Resource chính là dữ liệu nhưng mà chúng ta nên quản lý, rất có thể là customers, products, posts, images, videos… Mặt khác, thương hiệu resource cũng biến thành mở ra vào biện pháp viết endpoint, nên nếu như bạn khắc tên mang đến resource một cách công nghệ, thì endpoint cũng trở nên dễ hiểu cùng dễ tiếp cận hơn.

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

Endpoint Resource
http://api.example.com/users users
http://api.example.com/users/1/accounts accounts
http://api.example.com/users/1/images images

Dưới đấy là một vài luật lệ nhằm các bạn tham khảo về kiểu cách đánh tên resource làm sao để cho tốt.

Sử dụng danh từ bỏ để tại vị thương hiệu 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, vì vậy resource buộc phải được đặt tên dưới dạng dạng một danh từ bỏ chđọng chưa phải một đụng tự. Giả sử bản thân có một số resource là: users, posts, thì resource khớp ứng sẽ tiến hành viết trong số endpoint như sau:

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

Trong thực tế, các resource thông thường sẽ có quan hệ cùng nhau. lấy một ví dụ bản thân tất cả resource user, mỗi user lại có nhiều resource image. Thì minch có thể xây cất những endpoint nlỗi sau

http://api.example.com/users # Liệt kê tất cả usershttp://api.example.com/users/1 # Chi tiết user gồm ID là 1http://api.example.com/users/1/images # Liệt kê toàn bộ images của user bao gồm ID là 1Dùng dấu gạch ốp ngang (-) nhằm chia cách giữa các các 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 tốt (3)Trong ví dụ trên, phương pháp (1) và (2) rõ ràng là đọc dễ dàng rộng những so với phương pháp (3). Một số bạn theo công ty cmùi hương của camelcase hoàn toàn có thể đang thấy cách (3) dễ đọc hơn. Tuy nhiên nếu như mình có caiTenDaiNgoangNgoang gắng này thì cụ thể khó khăn chú ý rộng cai-ten-dai-ngoang-ngoang rứa này đúng không nào.

Vậy vì sao (1) lại xuất sắc hơn (2)? Nguyên nhân là dâu gạch bên dưới (_) bị dựa vào các vào phông chữ hiển thị, vào một vài ngôi trường hòa hợp nó rất có thể bị bịt mất 1 phần, hoặc bị xóa, hoặc bị chuyển thành vệt cách trên một số trình chú ý. Vấn đề này dễ dãi gây ra lầm lẫn cho người sử dụng.

Sử dụng chữ hay cho toàn bộ endpoint

http://api.example.com/banned-users # Tốt (1)HTTP://API.WEBSERVICE.COM/banned-users # Không tốt (2)http://api.example.com/BANNED-USERS # Không tốt (3)Trong mỗi endpoint, không tính phần giao thức và phần domain, thì các phần còn sót lại đã phân minh chữ hoa chữ thường xuyên. Tức là ta bao gồm endpoint (1) sẽ tương tự với endpoint (2), tuy thế endpoint (3) thì không giống hoàn toàn.

Vậy nhằm đồng bộ và tránh nhầm lẫn, họ đề xuất viết các endpoint bằng văn bản hay.

Không áp dụng đuôi mở rộng cho các endpoint

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

Endpoint dài hơn cùng quan sát có vẻ xấu xíquý khách hàng đang buộc phải gia hạn những endpoint hơn

Nếu nhỏng chúng ta vẫn hy vọng endpoint rất có thể trả về không ít kiểu dữ liệu không giống nhau, thì bạn có thể thực hiện nằm trong tính Content-Type của request header để khẳng định kiểu dá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 list cục bộ users. Nhưng thực tiễn mình chỉ hy vọng lôi ra những users ngơi nghỉ Việt Nam. Một số các bạn sẽ nghĩ mang đến cách chế tạo ra một endpoint nlỗi phong cách nhỏng /users/vn để xử lý thử khám phá này. Tuy nhiên bạn không nhất thiết phải làm cho vắt, chúng ta cũng có thể coi Việt Nam như một tiêu chí nhằm thanh lọc, với endpoint nên được viết như thế này

http://api.example.com/users?country=vn # xuất sắc. Sử dụng query params countryhttp://api.example.com/users/vn # ko tốtquý khách hàng cũng yêu cầu áp dụng query params để phân trang hoặc bố trí công dụng cố gắng bởi vì câu hỏi xây dự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=lathử nghiệm # Tốthttp://api.example.com/users/orderBy/lathử nghiệm # Không tốthttp://api.example.com/users/orderBy?lakiểm tra # Không tốtSử dụng HTTPhường method để biểu đạt CRUD

Quý khách hàng tránh việc biểu hiện những thao tác làm việc với resource bởi câu hỏi đã cho thấy trên URI, nuốm vào đó bạn hãy thực hiện các HTTP method tương xứng.

# Liệt kê list usersHTTP. GET http://api.example.com/users # NênHTTP.. GET http://api.example.com/users/all # Không nên# Thêm một users bắt đầu vào danh sáchHTTP POST http://api.example.com/users # NênHTTP. POST http://api.example.com/users/create # Không nênHTTPhường 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ênHTTP. 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ó duy nhất thiết cần theo đúng 100% chuẩn RESTful không?Thực tế bản thân trải qua các dự án công trình sử dụng RESTful thì chưa tồn tại dự án công trình làm sao thực hiện được 100% chuẩn chỉnh của RESTful, bởi

Đa phần các developer chỉ đam mê sử dụng method POST cùng GET mang lại đối kháng giảnMột số ý kiến cho rằng /users/1 cạnh tranh sử dụng rộng /users?id=1

Vậy gồm độc nhất thiết là phải chuẩn chỉnh 100% RESTful không? Câu trả lời là không, chuẩn chỉnh của RESTful là 1 trong những chuyện nhưng nó cũng cần phù hợp với việc thống tốt nhất của team, cân xứng cùng với tính chất của dự án công trình. Nhưng ý kiến của mình là càng chuẩn chỉnh RESTful thì sẽ càng xuất sắc.

III. API là gì với 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 ở đây chưa phải là bối cảnh của phần mềm, chưa phải là mọi kăn năn màu, bố cục tổng quan của ứng dụng mà lại đôi mắt các bạn nhìn thấy đâu đấy. Giao diện tại đây y hệt như một chuẩn thông thường nhằm kết nối vậy. lấy ví dụ như cái ổ cắn cùng với dòng phích cắn, tuy nhiên bọn chúng có thể đến từ nhì đơn vị sản xuất khác nhau cơ mà Khi cắn sát vào nhau thì chúng vẫn vừa vặn, đấy là vị chúng cùng tuân theo một hình ảnh kết nối.

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

3.2 RESTful API là gì?

RESTful API là phần đa API của web service thực hiện theo chuẩn RESTful. Trước lúc áp dụng RESTful nhằm chế tạo API, người ta đang đưa ra các chuẩn (API) trước. lấy ví dụ như bản thân nguyên tắc trường hợp tiến hành thêm users thành công xuất sắc, thì đã yêu cầu trả về header status là 200, kèm một tin nhắn có văn bản là “thành công” chẳng hạn, ai nhưng có tác dụng không đúng theo quy tắc này Tức là không nên API, cùng endpoint này sẽ chỉ được xem là RESTful endpoint chứ không cần được coi là RESTful API.

IV. Lời kết

kết luận lại, bài viết này mình muốn các bạn giữ một số trong những ý chính sau:

RESTful chỉ là 1 trong chuẩn của website service, muốn biết về RESTful thì yêu cầu khám phá về website service trước.RESTful không cực nhọc, nó chỉ là 1 tập các nguyên tắc thôi, tuân theo quy tắc này Có nghĩa là các bạn đang làm cho được RESTful

Bạn đề nghị làm gì tiếp theo?

Nếu chúng ta đã có lần thao tác làm việc cùng với RESTful rồi, độc giả bài viết này chỉ để củng nỗ lực thêm kỹ năng thì bản thân hy vọng các bạn vẫn đọc hơn về nó qua giải pháp phân tích và lý giải của chính bản thân mình. Còn nếu bạn chưa từng thao tác với RESTful, hoặc đó là lần trước tiên các bạn nghe thấy tư tưởng này, thì bạn nên có tác dụng một demo web service nhỏ tuổi vận dụng RESTful nhằm đọc hơn nhé, chứ tất cả giải thích hay núm nào thì bài viết này của bản thân mình cũng chỉ với lý thuyết mà thôi.

Bài viết được viết dựa trên tay nghề làm việc của chính bản thân mình cùng tìm hiểu thêm một số trong những nguồn. Xin dìm gần như gạch đá.

Tài liệu tyêu thích khảo: https://restfulapi.net

(*) CURL: là cỗ thỏng viện được áp dụng sẽ giúp đỡ thực hiện vấn đề chuyển dữ liệu thông qua các giao thức khác biệt nhỏng HTTPhường, FPT…

Bài viết xem nhiều