Web service api là gì

Có phải bạn là một trong những developer bắt đầu, chúng ta thấy những developer tay nghề cao không giống nói cùng nhau về restful. Quý khách hàng đắn đo restful là gì đề xuất các bạn lên google search “restful là gì?”. Quý khách hàng gọi không ít nội dung bài viết rồi tuy nhiên vẫn còn đấy mông lung chưa hiểu khía cạnh mũi thằng restful cầm cố nào? Nếu nlỗi nhiều người đang cảm giác những điều đó, thì hãy xem thêm nội dung bài viết này của bản thân mình nhé.

Bạn đang xem: Web service api là gì

Bài viết này mình đang trình bày số đông vẫn đề bao quanh restful api trước lúc bản thân trình bày cụ thể về nó, vậy nên bạn hãy kiên nhẫn gọi 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ì ai cũng cũng biết rồi, như blog phambinch.net này chính là một website kia. Thế tuy vậy web service thì không giống, không phải ai cũng gồm cơ hội được nghe thấy nhiều từ này kể từ thời điểm nhưng Restful trsinh hoạt cần thịnh hành.

Web service cũng là 1 trong những áp dụng website vận động tựa như nlỗi một website, Tức là để truy vấn vào website service bạn có thể mnghỉ ngơi trình cẩn thận lên, gõ vào thanh hao liên quan url của website service kia. Tuy nhiên khác cùng với trang web – web nhằm cho tất cả những người gọi, thì web service sinh ra để cho những máy bộ, hoặc các áp dụng không giống phát âm.

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

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

Quang nghĩ mang lại cách vẫn cyếu “cứng” truyền bá của chính 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ì ckém cứng những điều đó, lỡ job PHPhường của Quang hết hạn sử dung tuyển dụng thì sao, lại gỡ xuống à? Mà một job thì không vấn đề gì, chứ đọng 100 job thì chỉ gồm cnhát 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, “bên website tuyển dụng của ngươi, ngươi tạo cho tao một trang riêng rẽ chỉ hiển thị các job PHPhường. mà mày muốn truyền bá, bên website của tao đang đọc văn bản website này rồi hiển thị lên“.

Vậy là Quang tạo thành một website riêng rẽ đến Bình tại địa chỉ http://webtuyendungit.com/job-php, khi truy cập vào đây đã chỉ nhận thấy câu chữ nặng nề hiểu nhỏng sau

"jobs": < "url": "http://webtuyendungit.com/tuyen-lap-trinh-vien-php-luong-1000-dollar", "title": "Tuyển dụng xây dựng 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 xây dựng viên PHPhường không kinh nghiệm" , >Sau kia, Bình thực hiện CURL để mang câu chữ trên website của Quang, đối chiếu thành tài liệu với hiển thị ngon lành lên website huấn luyện và giảng dạy của bản thân. Giờ phía trên Quang ý muốn thay đổi câu chữ quảng bá thì chỉ cần chuyển đổi ngôn từ của trang web bên trên, khôn cùng thuận lợi và dữ thế chủ động.

Trên chính là một ví dụ điển của website service. lúc các áp dụng không liên quan tới nhau, mà lại vẫn mong mỏi trao đổi dữ liệu với nhau thì bạn ta vẫn suy nghĩ ngay lập tức tới bài toán áp dụng web service. Một web service vẫn trả về tài liệu theo một cấu tạo như thế nào kia (XML hoặc JSON,…) nhằm các vận dụng khác hoàn toàn có thể hiểu, so sánh với thực hiện được. Nlỗi ví dụ bên trên thì http://webtuyendungit.com/job-php đó là endpoint của một website service.

Web service Thành lập và hoạt động nhỏng là một trong những điều phân minh, bởi vì càng ngày càng có khá nhiều hệ thống chạy nhiều nền tảng nlỗi Facebook, Youtube,.. thành lập và hoạt động. đặc điểm của các khối hệ thống chạy đa nền tảng này là luôn luôn đòi hỏi tài năng đồng điệu dữ liệu. lấy một ví dụ chúng ta like một status facebook trên website, thì trên tiện ích cũng bắt buộc được diễn tả, chúng ta đăng một bức ảnh lên facebook trường đoản cú Mobile, thì bên trên web cũng yêu cầu thấy được. Để làm cho được vấn đề đó, tín đồ ta sẽ tạo nên ra một bé website service, để khi bạn đăng hình họa, like xuất xắc tiến hành bất kỳ hành vi gì hầu hết đề xuất Gọi cho tới web service này mặc dù hành vi này được triển khai từ bỏ website tốt điện thoại. Mặt khác, áp dụng website với thiết bị di động sẽ kết nối vào chung website service nhằm đọc dữ liệu, vày vậy sẽ bảo vệ được tài liệu là tương đương nhau mặc dầu bên trên các nền tảng gốc rễ khác biệt.

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

Giúp các hệ thống ko liên quan cho tới nhau vẫn rất có thể giao tiếp được với nhauĐồng bộ tài liệu thân các nền tảng
*
Web service ở giữa
1.2 Endpoint của web service

Mỗi URL kèm HTTPhường method của web service thì được Hotline là một trong những endpoint, nhỏng ví dụ bên trên thì mình tất cả http://webtuyendungit.com/job-phpđó là một endpoint. Lúc làm một endpoint mang đến web service, bạn sẽ phải quyên tâm cho tới một trong những vụ việc sau:

Endpoint sử dụng kết cấu tài liệu nào để trả về?

XML hoặc JSON là nhì chọn lọc cho bạn để sử dụng làm cho dữ liệu trả về cho endpoint. Nhỏng ví dụ bên trên là mình thực hiện JSON.

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

lấy ví dụ như bản thân có 1 endpoint trả về ban bố chi tiết của một user phụ thuộc ID của user được gửi lên, thì bản thân hoàn toàn có thể lựa chọn 1 vào hai biện 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 bạn cũng có thể cần sử dụng một biện pháp viết khác cũng rất được, nói chung là endpoint được viết như thế nào là vì bạn, không có luật lệ tầm thường nào cho bí quyết viết endpoint cả.

URL thực hiện HTTPhường Method nào?

Giả sử bản thân lựa chọn URL gồm dạng là http://webservice.com/users?id=1, nắm HTTP method là gì được nhỉ? GET hay POST? Câu vấn đáp cũng chính là tùy các bạn, GET tốt POST cũng khá được, không có quy tắc như thế nào cả.

An toàn dữ liệu

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

1.3 Các loại web service

Các endpoint của website service vượt “tự do”, dữ liệu trả về, biện pháp viết url, http method phần đông vày các bạn tự quyết định. Nhận thấy vấn đề này không phù hợp, đề nghị người ta chỉ dẫn nhì một số loại chuẩn mang lại web service nlỗi sau:

SOAP. web service

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

RESTful website service

REpresentational State Transfer, là một chuẩn chỉnh của website service. RESTful hoàn toàn có thể thực hiện JSON, XML, plain text, html,.. làm cho kết cấu tài liệu trả về, bao gồm quy ước ví dụ về phong thái viết url và http method. Nhưng RESTful ko cung cấp hiệ tượng đảm bảo an toàn lên tiếng trong số endpoint như SOAPhường. Tuy nhiên chúng ta cũng có thể sử dụng Json Web Token kết hợp với RESTful để xử lý vấn đề này, nên việc không tồn tại sẵn phương pháp an toàn lên tiếng chưa hẳn là vấn đề xứng đáng sốt ruột Khi áp dụng RESTful.

SOAP.. vs RESTful

Ngày ni các dự án công trình web service phần lớn (thậm chí là gần như tất cả) những áp dụng RESTful thay bởi vì thực hiện SOAP. Bởi nhỏng bản thân nhắc ra sống bên trên thì bạn thấy RESTful bao gồm quy ước rõ ràng hơn hẳn SOAP.. Mặt khác RESTful hoàn toàn có thể thực hiện 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 ở góc độ nào kia có thể nói rằng RESTful bao gồm cả SOAPhường cũng ko không đúng.

Tuy nhiên SOAP.. vẫn tồn tại được thực hiện trong không ít dự án cũ rất cần được duy trì, cần bạn cơ mà tò mò được SOAP. nữa thì càng xuất sắc.

II. Tìm hiểu về RESTful

Bài viết viết về RESTful mà lại thừa ttách về web service. Mình trình bày như thế là do theo như đúng trình trường đoản cú thì loại chúng ta biết trước đề nghị là website service, sau đó new là RESTful. Nhưng do RESTful vẫn là 1 trong từ bỏ khóa hot, nên chúng ta bao gồm xu hướng tò mò về RESTful trước mà lại không để ý mất cái cội web service.

Xem thêm: Mã Bưu Chính Là Gì? Bảng Zip Code Là Gì Vậy Zip Code Là Gì Vậy

Sau trên đây new thiệt sự là tất cả những gì bạn muốn tò mò về RESTful nhé.

RESTful gồm khối hệ thống nguyên tắc nghiêm ngặt về những viết endpoint cùng HTTP.. method, mình vẫn bắt tắt một vài cơ chế đặc biệt quan trọng tạo ra sự “tên tuổi” của RESTful nhằm các bạn một thể theo dõi.

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

Nếu là web developer, chắc chắn là các bạn biết đến method GET cùng POST. Nhưng với RESTful thì có thêm một số trong những method new, kèm phương pháp sử dụng khớp ứng nhỏng sau:

GET: được sử dụng để mang biết tin tự sever theo URI đang cung cấp.POST: gửi thông báo cho tới máy chủ thông qua những biểu mẫu http (đăng kí chả hạn..)HEAD: giống cùng với GET tuy thế response trả về không tồn tại body toàn thân, chỉ bao gồm headerPUT: ghi đè cổ tất cả thông tin của đối tượng với đầy đủ gì được gửi lênPATCH: ghi đè những thông tin được biến đổi của đối tượng người sử dụng.DELETE: xóa tài nguyên ổn bên trên server.CONNECT: tùy chỉnh thiết lập một kết nối tới hệ thống theo URI.OPTIONS: mô tả các tùy lựa chọn tiếp xúc mang đến resource.TRACE: triển khai một bài bác chạy thử loop – bachồng theo băng thông mang lại resource.

Thực tế thì mình new chỉ thao tác cùng với những method GET, POST, PUT, DELETE thôi, những method còn sót lại thì chưa có tác dụng lúc nào, nhưng sau này chắc là vẫn chạm mặt :p.

2.2 Quy ước về resource, endpoint

Resource có nghĩa là tài nguim, mà lại đó là một có mang được nói tới những trong RESTful, đề nghị mình vẫn không thay đổi từ khóa này mà lại ko Việt hóa nhé.

Resource chính là tài liệu nhưng bọn họ yêu cầu thống trị, có thể là customers, products, posts, images, videos… Mặt khác, tên resource cũng trở thành mở ra vào bí quyết viết endpoint, yêu cầu nếu bạn đánh tên mang lại resource một giải pháp công nghệ, thì endpoint cũng trở thành dễ nắm bắt cùng dễ dàng tiếp xúc rộng.

Xem ví dụ vào bảng sau nhằm hiểu rõ đâu là resource, với resource thường xuyên được viết như 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 quy tắc nhằm chúng ta xem thêm về cách viết tên resource làm thế nào cho hay.

Sử dụng danh tự để đặt tên mang đến resource

RESTful tổ chức resource dưới dạng những đối tượng người dùng, vày vậy resource cần chọn cái tên bên dưới dạng dạng một danh trường đoản cú chứ đọng chưa hẳn một cồn từ bỏ. Giả sử mình có một số resource là: users, posts, thì resource tương xứng sẽ tiến hành viết trong những endpoint như sau:

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

Trong thực tiễn, những resource thường sẽ có mối quan hệ cùng nhau. lấy ví dụ mình tất cả resource user, từng user lại có khá nhiều resource image. Thì minc rất có thể xây đắp các endpoint nhỏng sau

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

Vậy tại vì sao (1) lại tốt hơn (2)? Nguyên nhân là dâu gạch men dưới (_) bị dựa vào các vào phông chữ hiển thị, trong một số trường hợp nó có thể bị bít mất một phần, hoặc bị xóa, hoặc bị đưa thành vết cách bên trên một vài trình xem xét. Như vậy tiện lợi tạo ra nhầm lẫn cho tất cả những người áp dụng.

Sử dụng chữ thường xuyên đế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, quanh đó phần giao thức cùng phần domain name, thì những phần còn lại đã biệt lập chữ hoa chữ hay. Tức là ta tất cả endpoint (1) đang tương tự cùng với endpoint (2), nhưng mà endpoint (3) thì khác trọn vẹn.

Vậy để nhất quán và tránh lầm lẫn, bọn họ buộc phải viết những endpoint bằng văn bản thường.

Không thực hiện đuôi không ngừng mở rộng cho những endpoint

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

Endpoint dài ra hơn nữa với quan sát dường như xấu xíBạn vẫn phải duy trì các endpoint hơn

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

Sử dụng query params nhằm thanh lọc kết quả

Giả sử mình bao gồm một endpoint /users để đưa ra danh sách cục bộ users. Nhưng thực tiễn mình chỉ mong muốn mang ra các users sinh sống cả nước. Một số các bạn sẽ suy nghĩ cho cách tạo một endpoint nlỗi vẻ bên ngoài nhỏng /users/vn để giải quyết từng trải này. Tuy nhiên các bạn không cần phải làm cho chũm, bạn có thể coi Việt Nam nhỏng một tiêu chuẩn để lọc, và endpoint phải được viết như thế này

http://api.example.com/users?country=vn # giỏi. Sử dụng query params countryhttp://api.example.com/users/vn # không tốtquý khách cũng cần sử dụng query params để phân trang hoặc sắp xếp công dụng nắm do việc kiến thiết 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=lademo # Tốthttp://api.example.com/users/orderBy/lathử nghiệm # Không tốthttp://api.example.com/users/orderBy?latest # Không tốtSử dụng HTTPhường method để thể hiện CRUD

Quý khách hàng không nên biểu lộ những thao tác làm việc cùng với resource bởi Việc đã cho thấy trên URI, cố kỉnh vào đó bạn hãy thực hiện những HTTPhường method khớp ứng.

# Liệt kê list usersHTTP GET http://api.example.com/users # NênHTTPhường 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ênHTTPhường POST http://api.example.com/users/store # Không nên# Cập nhật báo cáo user bao gồm ID là 1HTTP 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 bao gồm ID là 1HTTPhường 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 thủ theo đúng 100% chuẩn RESTful không?Thực tế bản thân trải qua những dự án công trình thực hiện RESTful thì chưa tồn tại dự án nào tiến hành được 100% chuẩn chỉnh của RESTful, bởi

Đa phần những developer chỉ ưng ý cần sử dụng method POST cùng GET mang lại đơn giảnMột số chủ ý nhận định rằng /users/1 khó khăn thực hiện rộng /users?id=1

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

III. API là gì cùng RESTful API là gì?

3.1. API là gì?

API là viết tắt của Application Programing Interface – đồ họa lập trình áp dụng. Giao diện ở đây không hẳn là giao diện của phần mềm, chưa phải là đa số khối màu, bố cục tổng quan của ứng dụng mà lại mắt bạn bắt gặp đâu nhé. Giao diện tại đây hệt như một chuẩn chỉnh tầm thường nhằm liên kết vậy. lấy một ví dụ như loại ổ cắm với mẫu phích cắm, mặc dù bọn chúng có thể đến từ hai bên chế tạo khác nhau dẫu vậy Lúc gặm vào nhau thì bọn chúng vẫn vừa khít, đây là vì chưng bọn chúng thuộc tuân thủ theo đúng một bối cảnh kết nối.

Vì một phần mềm chứa tương đối nhiều logic phức tạp, nên người ta tìm cách chia nhỏ nó ra thành phần nhiều, từng phần này tạm gọi là 1 trong component. Mỗi component sẽ sở hữu tính độc lập cao, ít nhờ vào hoặc rất có thể ko phục thuộc vào những yếu tố không giống. Tuy là bao gồm tính hòa bình cao, mà lại nhằm rất có thể liên kết được cùng nhau nhưng một trong những phần mượt 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 vài chuẩn chỉnh làm sao kia. Thì từng dòng chuẩn đó được hotline là 1 trong đồ họa thiết kế vận dụng – hay chính là một API.

3.2 RESTful API là gì?

RESTful API là rất nhiều API của web service thực hiện theo chuẩn chỉnh RESTful. Trước lúc vận dụng RESTful để chế tạo ra API, tín đồ ta đang chỉ dẫn những chuẩn (API) trước. lấy ví dụ như mình lao lý giả dụ triển khai thêm users thành công, thì đang đề xuất trả về header status là 200, kèm một tin nhắn gồm nội dung là “thành công” ví dụ điển hình, ai cơ mà làm không đúng theo quy tắc này Tức là không nên API, với endpoint đó sẽ chỉ được xem là RESTful endpoint chứ không hề được xem như là RESTful API.

IV. Lời kết

Tóm lại lại, nội dung bài viết này mình thích các bạn giữ một trong những ý bao gồm sau:

RESTful chỉ là 1 chuẩn của web service, ao ước biết về RESTful thì phải mày mò về website service trước.RESTful không khó khăn, nó chỉ là 1 trong những tập những nguyên tắc thôi, tuân theo phép tắc này có nghĩa là các bạn vẫn làm được RESTful

quý khách hàng cần làm những gì tiếp theo?

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

Xem thêm: Hướng Dẫn Cài Đặt Talking Tom 2 Trên Máy Tính, My Talking Tom

Bài viết được viết dựa trên kinh nghiệm tay nghề thao tác làm việc của chính mình cùng tham khảo một số trong những mối cung cấp. Xin nhấn gần như gạch đá.

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

(*) CURL: là cỗ tlỗi viện được sử dụng để giúp triển khai vấn đề đưa tài liệu thông qua các giao thức khác nhau nlỗi HTTP.., FPT…


Chuyên mục: Review công nghệ