Restful api là gì

Có buộc phải chúng ta là một trong những developer new, chúng ta thấy những developer tay nghề cao khác nói với nhau về restful. quý khách không biết restful là gì bắt buộc các bạn lên google search “restful là gì?”. Quý khách hàng gọi tương đối nhiều bài viết rồi nhưng vẫn còn đó mung lung không biết khía cạnh mũi thằng restful thế nào? Nếu nhỏng ai đang Cảm Xúc điều này, thì hãy xem thêm nội dung bài viết này của mình nhé.

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

Bài viết này mình sẽ trình diễn phần đông vẫn đề bao quanh restful api trước lúc bản thân trình bày chi tiết về nó, thế nên các bạn hãy kiên nhẫn phát âm nhé.


Mục lục


I. Web service là gì?II. Tìm hiểu về RESTfulIII. API là gì và RESTful API là gì?

I. Web service là gì?

Website thì ai ai cũng cũng biết rồi, nhỏng blog phambinc.net này chính là một trang web kia. Thế dẫu vậy website service thì không giống, chưa hẳn người nào cũng có cơ hội được nghe thấy các tự này kể từ thời điểm nhưng mà Restful trnghỉ ngơi buộc phải phổ cập.

Web service cũng là 1 trong những ứng dụng web chuyển động tương tự như như một trang web, Có nghĩa là để truy cập vào website service chúng ta có thể msống trình chuẩn y lên, gõ vào tkhô giòn thúc đẩy url của website service đó. Tuy nhiên khác cùng với website – web nhằm cho tất cả những người phát âm, thì web service xuất hiện khiến cho các máy bộ, hoặc những ứng dụng khác phát âm.

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

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

Quang nghĩ mang lại biện pháp vẫn cyếu “cứng” truyền bá của chính bản thân mình trong những khóa học của Bình, tuy nhiên Bình gạt đi. Vì cyếu cứng điều này, 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ì chẳng sao, chứ đọng 100 job thì chỉ có cyếu lên cùng với gỡ xuống cũng không còn ngày. Bình bèn nghĩ về ra phương pháp này với bảo Quang, “bên trang web tuyển chọn dụng của mày, mi tạo cho tao một trang riêng biệt chỉ hiển thị những job PHPhường nhưng mày mong muốn PR, bên trang web của tao đang hiểu câu chữ trang web này rồi hiển thị lên“.

Vậy là Quang chế tác một website riêng mang lại Bình ở địa chỉ http://webtuyendungit.com/job-php, lúc truy vấn vào chỗ này đang chỉ thấy được văn bản cực nhọc đọc nlỗi sau

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

Trên đó là một ví dụ điển của website service. lúc các vận dụng không tương quan tới nhau, tuy nhiên vẫn mong thảo luận tài liệu cùng nhau thì bạn ta đang nghĩ về ngay lập tức cho tới việc áp dụng website service. Một website service sẽ trả về tài liệu theo một kết cấu nào đó (XML hoặc JSON,…) nhằm những áp dụng khác rất có thể hiểu, phân tích với áp dụng được. Nlỗi ví dụ bên trên thì http://webtuyendungit.com/job-php chính là endpoint của một website service.

Web service thành lập nhỏng là một trong điều hiển nhiên, chính vì càng ngày càng có tương đối nhiều khối hệ thống chạy nhiều nền tảng như Facebook, Youtube,.. thành lập và hoạt động. Điểm lưu ý của các hệ thống chạy đa nền tảng này là luôn luôn đề xuất kỹ năng đồng nhất dữ liệu. Ví dụ bạn lượt thích một status facebook bên trên website, thì trên ứng dụng cũng yêu cầu được biểu lộ, các bạn đăng một tấm hình lên facebook từ mobile, thì trên web cũng phải bắt gặp. Để có tác dụng được vấn đề này, tín đồ ta sẽ tạo ra một bé website service, nhằm khi bạn đăng hình họa, like giỏi triển khai ngẫu nhiên hành động gì hầu hết đề xuất Gọi cho tới website service này mặc dầu hành vi này được thực hiện trường đoản cú website hay Mobile. Mặt khác, vận dụng web và di động đã liên kết vào bình thường website service để đọc tài liệu, do vậy đã bảo đảm an toàn được dữ liệu là giống như nhau mặc dù trên các căn nguyên không giống nhau.

Tóm lại website service Thành lập và hoạt động nhằm xử lý một vấn đề sau

Giúp các hệ thống không liên quan cho tới nhau vẫn có thể giao tiếp được với nhauĐồng cỗ tài liệu thân những nền tảng
*
Web service nằm giữa
1.2 Endpoint của web service

Mỗi URL kèm HTTP. method của website service thì được Hotline là một trong endpoint, nhỏng ví dụ trên thì bản thân gồm http://webtuyendungit.com/job-phpđó là một endpoint. khi làm một endpoint mang lại web service, các bạn sẽ buộc phải quan tâm tới một vài vấn đề sau:

Endpoint áp dụng cấu trúc dữ liệu như thế nào để trả về?

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

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

Ví dụ mình có 1 endpoint trả về lên tiếng chi tiết của một web3_user dựa vào ID của web3_user được gửi lên, thì mình rất có thể lựa chọn một vào hai bí quyết viết sau (đưa sử ID của web3_user là 1).

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

Hoặc chúng ta có thể sử dụng một bí quyết viết khác cũng rất được, nói thông thường là endpoint được viết ra sao là do bạn, không tồn tại luật lệ chung như thế nào cho biện pháp viết endpoint cả.

URL thực hiện HTTP Method nào?

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

An toàn dữ liệu

Web service điều đình dữ liệu cùng với các áp dụng không giống trải qua môi trường mạng. Nếu nhằm lộ các endpoint, thì tài năng cao dữ liệu trả về trong các endpoint đó cũng trở nên lộ. Thực tế đã có nhiều vụ lộ lên tiếng người dùng nhưng ngulặng nhân là vì những endpoint kém nhẹm bảo mật thông tin.

1.3 Các một số loại web service

Các endpoint của web service quá “từ do”, dữ liệu trả về, cách viết url, http method những vì chúng ta trường đoản cú đưa ra quyết định. Nhận thấy điều này ko hợp lý và phải chăng, yêu cầu người ta đưa ra nhì loại chuẩn chỉnh cho website service nlỗi sau:

SOAP website service

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

RESTful website service

REpresentational State Transfer, là một chuẩn của web service. RESTful rất có thể áp dụng JSON, XML, plain text, html,.. làm cho cấu tạo dữ liệu trả về, bao gồm quy ước ví dụ về phong thái viết url cùng http method. Nhưng RESTful ko hỗ trợ cơ chế đảm bảo an toàn đọc tin trong những endpoint nlỗi SOAP. Tuy nhiên bạn cũng có thể sử dụng Json Web Token kết hợp với RESTful để xử lý vấn đề này, cho nên việc không có sẵn phép tắc an ninh ban bố không hẳn là vấn đề đáng khiếp sợ khi thực hiện RESTful.

SOAPhường vs RESTful

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

Tuy nhiên SOAP vẫn tồn tại được sử dụng trong nhiều dự án cũ rất cần phải duy trì, bắt buộc các bạn nhưng tìm hiểu được SOAPhường. nữa thì sẽ càng giỏi.

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

Bài viết viết về RESTful và lại quá ttách về web service. Mình trình bày điều này là do theo như đúng trình tự thì mẫu họ biết trước yêu cầu là web service, tiếp đến new là RESTful. Nhưng vị RESTful sẽ là một trong từ bỏ khóa hot, đề nghị các bạn gồm xu hướng mày mò về RESTful trước mà lại xem nhẹ mất chiếc gốc web service.

Xem thêm: Sale Off Là Gì ? Phân Biệt Sale Off Và Sale Up To Thế Nào Mới Đúng

Sau trên đây new thật sự là các thứ bạn muốn tò mò về RESTful nhé.

RESTful có khối hệ thống luật lệ nghiêm ngặt về những viết endpoint và HTTP method, mình sẽ nắm tắt một vài ba nguyên tắc đặc biệt làm nên “tên tuổi” của RESTful để chúng ta tiện thể theo dõi.

2.1 Quy tắc về HTTPhường. method của endpoint

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

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

Thực tế thì bản thân mới chỉ thao tác cùng với các method GET, POST, PUT, DELETE thôi, các method còn lại thì chưa làm lúc nào, cơ mà sau này chắc chắn rằng đang gặp gỡ :p.

2.2 Quy ước về resource, endpoint

Resource tức là tài ngulặng, tuy thế đó là một quan niệm được nhắc tới những vào RESTful, buộc phải mình sẽ không thay đổi keywords này mà lại ko Việt hóa nhé.

Resource đó là tài liệu nhưng mà họ bắt buộc thống trị, hoàn toàn có thể là customers, products, posts, images, videos… Mặt khác, tên resource cũng sẽ xuất hiện trong cách viết endpoint, yêu cầu nếu khách hàng đặt tên đến resource một bí quyết kỹ thuật, thì endpoint cũng bị dễ dàng nắm bắt cùng dễ tiếp cận rộng.

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

EndpointResource
http://api.example.com/web3_usersweb3_users
http://api.example.com/web3_users/1/accountsaccounts
http://api.example.com/web3_users/1/imagesimages

Dưới đó là một vài nguyên tắc nhằm chúng ta xem thêm về cách khắc tên resource sao để cho tốt.

Sử dụng danh từ bỏ để tại vị tên cho resource

RESTful tổ chức resource bên dưới dạng các đối tượng, bởi vậy resource yêu cầu được lấy tên dưới dạng dạng một danh từ chđọng chưa phải một cồn tự. Giả sử mình tất cả một số trong những resource là: web3_users, posts, thì resource tương ứng sẽ tiến hành viết trong số endpoint nhỏng sau:

http://api.example.com/web3_users # Liệt kê toàn bộ web3_userhttp://api.example.com/web3_users/1 # Chi ngày tiết web3_user có ID là 1http://api.example.com/posts # Liệt kê toàn bộ posthttp://api.example.com/posts/1 # Chi huyết post có ID là 1Sử dụng đấu sượt (/) nhằm bộc lộ quan hệ phân cấp giữa các resources

Trong thực tiễn, những resource thông thường có mối quan hệ với nhau. lấy ví dụ như bản thân có resource web3_user, mỗi web3_user lại có không ít resource image. Thì minh rất có thể xây đắp các endpoint nhỏng sau

http://api.example.com/web3_users # Liệt kê toàn bộ web3_usershttp://api.example.com/web3_users/1 # Chi máu web3_user bao gồm ID là 1http://api.example.com/web3_users/1/images # Liệt kê toàn bộ images của web3_user gồm ID là 1Dùng lốt gạch ốp ngang (-) để ngăn cách giữa những các từ

http://api.example.com/banned-web3_users # Tốt (1)http://api.example.com/banned_web3_users # Không xuất sắc (2)http://api.example.com/bannedUsers # Không tốt (3)Trong ví dụ bên trên, phương pháp (1) cùng (2) ví dụ là đọc dễ dàng rộng nhiều đối với bí quyết (3). Một số các bạn theo công ty chương thơm của camelcase hoàn toàn có thể đã thấy cách (3) dễ đọc rộng. Tuy nhiên giả dụ mình bao gồm caiTenDaiNgoangNgoang cố này thì ví dụ nặng nề chú ý hơn cai-ten-dai-ngoang-ngoang vậy này đúng không ạ.

Vậy tại sao (1) lại xuất sắc hơn (2)? Nguyên ổ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ố trong những trường phù hợp nó rất có thể bị che mất một phần, hoặc bị xóa, hoặc bị chuyển thành lốt cách trên một trong những trình chú ý. Vấn đề này tiện lợi tạo ra lầm lẫn cho những người sử dụng.

Sử dụng chữ thường xuyên đến toàn bộ endpoint

http://api.example.com/banned-web3_users # Tốt (1)HTTP://API.WEBSERVICE.COM/banned-web3_users # Không xuất sắc (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 cùng phần domain, thì các phần sót lại vẫn rõ ràng chữ hoa chữ hay. Tức là ta tất cả endpoint (1) vẫn tựa như cùng với endpoint (2), tuy thế endpoint (3) thì không giống trọn vẹn.

Vậy để nhất quán và nên tránh nhầm lẫn, bọn họ đề xuất viết các endpoint bằng văn bản thường xuyên.

Không sử dụng đuôi không ngừng mở rộng cho các endpoint

http://api.example.com/banned-web3_users # tốt (1)http://api.example.com/banned-web3_users.json # không tốt (2)http://api.example.com/banned-web3_users.xml # không tốt (3)Đuôi mở rộng đó là .json với .xml trong endpoint (2) với (3) ngơi nghỉ ví dụ trên. Một số chúng ta có thể thấy rằng những điều đó là tường minch hơn, rằng lúc tôi truyền .json nghĩa là tôi muốn lấy dữ liệu dạng json với giống như với xml. Tuy nhiên làm điều này không hẳn là bí quyết xuất xắc vì:

Endpoint dài hơn với chú ý dường như xấu xíQuý khách hàng đang đề xuất bảo trì các 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 nằm trong tính Content-Type của request header để xác minh kiểu dáng dữ liệu trả về.

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

Giả sử mình bao gồm một endpoint /web3_users để đưa ra danh sách tổng thể web3_users. Nhưng thực tế mình chỉ muốn lôi ra các web3_users sống nước ta. Một số các bạn sẽ suy nghĩ cho bí quyết sinh sản một endpoint nhỏng phong cách như /web3_users/vn nhằm xử lý kinh nghiệm này. Tuy nhiên chúng ta không cần thiết phải có tác dụng vậy, bạn cũng có thể coi Việt Nam nlỗi một tiêu chí để thanh lọc, và endpoint phải được viết như vậy này

http://api.example.com/web3_users?country=vn # giỏi. Sử dụng query params countryhttp://api.example.com/web3_users/vn # ko tốtquý khách hàng cũng đề xuất sử dụng query params nhằm phân trang hoặc thu xếp công dụng nạm do việc thi công một endpoint mới

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

quý khách không nên bộc lộ những làm việc với resource bởi bài toán chỉ ra trên URI, nạm vào đó bạn hãy áp dụng những HTTP method tương xứng.

# Liệt kê danh sách web3_usersHTTP. GET http://api.example.com/web3_users # NênHTTPhường GET http://api.example.com/web3_users/all # Không nên# Thêm một web3_users bắt đầu vào danh sáchHTTP POST http://api.example.com/web3_users # NênHTTP POST http://api.example.com/web3_users/create # Không nênHTTP.. POST http://api.example.com/web3_users/store # Không nên# Cập nhật báo cáo web3_user có ID là 1HTTPhường PUT http://api.example.com/web3_users/1 # NênHTTP.. POST http://api.example.com/web3_users/1/update # Không nênHTTPhường POST http://api.example.com/web3_users/1/edit # Không nên# Xóa web3_user tất cả ID là 1HTTP DELETE http://api.example.com/web3_users/1 # NênHTTPhường. POST http://api.example.com/web3_users/1/destroy # Không nênHTTP.. POST http://api.example.com/web3_users/1/delete # Không nên2.3 Có độc nhất thiết đề xuất tuân theo 100% chuẩn chỉnh 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 xuất hiện dự án nào triển khai được 100% chuẩn chỉnh của RESTful, bởi

Đa phần các developer chỉ say mê cần sử dụng method POST với GET cho 1-1 giảnMột số chủ ý cho rằng /web3_users/1 nặng nề sử dụng hơn /web3_users?id=1

Vậy tất cả duy nhất thiết là phải chuẩn 100% RESTful không? Câu trả lời là ko, chuẩn của RESTful là 1 cthị trấn tuy vậy nó cũng cần tương xứng với sự thống tốt nhất của team, cân xứng cùng với đặc thù của dự án. Nhưng ý kiến của chính 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ình ảnh thiết kế ứng dụng. Giao diện tại chỗ này chưa hẳn là đồ họa của phần mềm, chưa hẳn là số đông khối hận màu, bố cục của ứng dụng mà lại mắt các bạn thấy được đâu đấy. Giao diện ở đây giống như một chuẩn chỉnh tầm thường nhằm liên kết vậy. ví dụ như nlỗi loại ổ gặm với mẫu phích cắn, tuy vậy bọn chúng rất có thể đến từ nhì nhà sản xuất khác biệt nhưng lại khi cắn sát vào nhau thì bọn chúng vẫn vừa khít, đó là vày bọn chúng thuộc tuân thủ theo đúng một hình ảnh liên kết.

Vì 1 phần mượt cất rất nhiều logic phức tạp, nên người ta tra cứu phương pháp phân tách bé dại nó ra thành phần nhiều, từng phần này tạm thời Gọi là 1 trong những component. Mỗi component sẽ có tính tự do cao, ít phụ thuộc hoặc hoàn toàn có thể ko phục nằm trong vào các thành phần không giống. Tuy là bao gồm tính độc lập cao, mà lại nhằm có thể liên kết được với nhau nhưng một trong những phần mượt hoàn chỉnh, buộc chúng vẫn yêu cầu tuân theo một hoặc một số trong những chuẩn chỉnh làm sao đó. Thì từng dòng chuẩn này được call là 1 trong những bối cảnh lập trình vận dụng – tốt chính là một API.

3.2 RESTful API là gì?

RESTful API là đều API của website service sử dụng theo chuẩn RESTful. Trước khi vận dụng RESTful nhằm sản xuất API, bạn ta đang đưa ra các chuẩn chỉnh (API) trước. lấy ví dụ như bản thân luật pháp trường hợp thực hiện thêm web3_users thành công xuất sắc, thì sẽ buộc phải trả về header status là 200, kèm một lời nhắn bao gồm câu chữ là “thành công” chẳng hạn, ai mà lại làm không đúng theo nguyên tắc này Tức là không đúng API, với endpoint này sẽ chỉ được xem là RESTful endpoint chứ không hề được xem như là RESTful API.

IV. Lời kết

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

RESTful chỉ là một chuẩn chỉnh của web service, ý muốn biết về RESTful thì đề nghị khám phá về website service trước.RESTful không nặng nề, nó chỉ là một trong tập các phép tắc thôi, tuân theo nguyên tắc này Tức là các bạn đang có tác dụng được RESTful

quý khách buộc phải làm những gì tiếp theo?

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

Xem thêm: Level Of Significance Là Gì ? Định Nghĩa, Ví Dụ, Giải Thích

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 bản thân mình với tham khảo một số nguồn. Xin nhận hồ hết gạch đá.

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

(*) CURL: là cỗ thỏng viện được sử dụng để giúp triển khai câu hỏi chuyển tài liệu thông qua nhiều giao thức khác biệt nlỗi HTTP, FPT…


Chuyên mục: Kiến Thức