Xu Hướng 11/2022 # Api Là Gì Trong Java / 2023 # Top 17 View

Bạn đang xem bài viết Api Là Gì Trong Java / 2023 được cập nhật mới nhất trên website Ezlearning.edu.vn. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất.

Tất cả các lớp tích hợp này mang lại lợi ích cho lập trình viên. Chỉ lập trình viên hiểu làm thế nào để áp dụng lớp đó. Giao diện người dùng cung cấp sự tương tác cơ bản của người dùng giữa người dùng và máy tính, theo cách tương tự, API hoạt động như một giao diện chương trình ứng dụng mang lại kết nối giữa phần mềm cũng như người tiêu dùng. API bao gồm các lớp và gói thường hỗ trợ lập trình viên giảm thiểu các dòng của chương trình.

Tại sao chúng ta cần API trong Java?

Trong API Java, hơn 4500 API có sẵn trong Lập trình Java.

Hợp lý hóa các kỹ thuật

Hộp thư thông minh phát triển xã hội là một ví dụ tuyệt vời về điều này. Bạn sẽ đăng nhập vào Facebook và Twitter riêng lẻ, kiểm tra tin nhắn, vận hành các cụm từ tìm kiếm và trả lời khi bạn được gắn thẻ. Bây giờ, do các API mạng, bạn có thể quan sát tất cả điều này trong một chế độ xem, giảm thời gian bổ sung.

Ứng dụng giúp cuộc sống của bạn dễ dàng hơn

Nếu bạn đang sử dụng phương tiện giao thông công cộng, có thể bạn sẽ đi kèm với một ứng dụng, gợi ý khi xe buýt du lịch tiếp theo sẽ đến. Ứng dụng này mang lại lợi ích cho API quá cảnh cho thấy xe buýt nào sẽ đến và khi nào. Nó tiết kiệm thời gian của bạn và có thể trong trường hợp nếu bạn đang sống trong một môi trường lạnh.

Doanh nghiệp tăng

Tiềm năng kinh doanh có thể được mở rộng nếu họ cung cấp API. Bạn sẽ tìm thấy rất nhiều tài sản mà một công ty có thể cung cấp. Phát triển API có thể đạt được, với các nhà phát triển muốn phát triển tất cả chúng, có thể tăng các dịch vụ của họ cho các khách hàng bổ sung.

API Java chỉ đơn giản là trọng lượng nhẹ. Do đó, nếu bạn bị hạn chế băng thông sau đó, hãy chọn dịch vụ web REST rất đơn giản và nhanh chóng để xây dựng.

Sử dụng các trang web hàng đầu API Java như Twitter, Yahoo sử dụng loại mẫu này.

Hầu hết các trang truyền thông xã hội như chúng tôi đều có lợi cho các dịch vụ web REST.

Phát triển ứng dụng di động, đang phát triển nhanh chóng cũng như kết nối máy chủ của họ, bằng cách sử dụng mẫu REST này vì nó nhanh hơn trong việc xử lý dữ liệu yêu cầu và phản hồi.

RESTful API là gì?

Trong lập trình. RESTful API là một dạng tiêu chuẩn được sử dụng trong việc thiết kế API cho ứng dụng web để giúp quản lý resource một cách dễ dàng nhất. Chủ yếu quản lý các tài nguyên hệ thống như: Tệp văn bản, ảnh, âm thanh, video hoặc dữ liệu động… Trong đó phải kể đến là các tài nguyên được định dạng và được truyền tải thông qua HTTP.

RESTful là gì?

REST là viết tắt của cụm từ Representational State Transfer là một kiểu kiến trúc được sử dụng trong việc giao tiếp giữa các máy tính (máy tính cá nhân và máy chủ của trang web) trong việc quản lý các tài nguyên trên internet. REST sử dụng các cách biểu diễn khác nhau để biểu diễn các nguồn tài nguyên như text, JSON, XML nhưng phổ biến nhất vẫn là JSON. REST được sử dụng rất nhiều trong việc phát triển các ứng dụng Web Services sử dụng giao thức HTTP trong giao tiếp thông qua mạng internet. Các ứng dụng sử dụng kiến trúc REST này thì sẽ được gọi là ứng dụng phát triển theo kiểu RESTful.

Một đặc tính quan trọng của dịch Web service RESTful là sử dụng một cách rõ ràng các phương thức HTTP theo cách một giao thức được xác định bởi RFC 2616. Ví dụ HTTP GET được xác định như là một phương thức sinh ra số liệu được sử dụng có chủ đích bởi các ứng dụng người dùng để thu thập tài nguyên, dữ liệu từ một máy chủ, hoặc thực thi một truy vấn mà máy chủ sẽ tìm kiếm và phản hồi cùng với một gói thông tin tương thích.

REST yêu cầu các nhà phát triển sử dụng phương thức HTTP một cách rõ ràng theo cách tương thích với giao thức chuẩn. Nguyên lý thiết kế REST cơ bản này thiết lập một ánh xạ 1-1 giữa các hành động tạo, đọc, cập nhật và xoá (CRUD) các quá trình vận hành và các phương thức HTTP.

Theo cách ánh xạ này thì:

– Để truy xuất một tài nguyên, sử dụng GET.

– Để tạo một tài nguyên trên máy chủ, bạn cần sử dụng phương thức POST.

– Để thay đổi trạng thái một tài nguyên hoặc để cập nhật nó, sử dụng PUT.

– Để huỷ bỏ hoặc xoá một tài nguyên, sử dụng DELETE.

API là gì?

API là từ viết tắt của Application Programming Interface. Nó cho phép kết nối và trao đổi dữ liệu giữa hai hệ thống phần mềm riêng biệt. Một hệ thống phần mềm có thể nhúng các API bao gồm các hàm/thủ tục con (functions/sub-routines) mà có thể chạy bởi một hệ thống phần mềm khác.

Một sử dụng phổ biến của một API là khi bạn muốn để có được dữ liệu từ một ứng dụng (chẳng hạn như một công thức làm bánh) mà không cần phải thực sự truy cập các ứng dụng riêng của mình.

Để cho phép các hành động này diễn ra, ứng dụng đã xuất bản một API mà cụ thể cho phép cho các ứng dụng bên ngoài để thực hiện truy vấn đến các dữ liệu của nó và trả lại cho người dùng.

Trên trang web, điều này thường được thực hiện thông qua việc sử dụng RESTful URIs.

chúng tôi

Với API chúng ta sẽ xây dựng ở đây sẽ bao gồm hai lớp. Một lớp trừu tượng (Abstract class in PHP) sẽ xử lý các phân tích của các URI và trả lại phản hồi, và một lớp con cụ thể sẽ chứa các điểm cuối (endpoints) cho API. Bằng cách này, chúng ta có được một lớp trừu tượng có thể tái sử dụng và có thể trở thành nền tảng của bất kỳ RESTful API khác.

Việc đầu tiên chúng ta sẽ tạo ra 1 file .htaccess với nội dung sau:

Bây giờ chúng ta sẽ tạo 1 Abstract class.

Như đã đề cập trước đó, lớp này sẽ đóng vai trò như là một lớp bao phủ cho tất cả các endpoints tùy chỉnh thứ mà API sẽ sử dụng. Nó sẽ nhận request từ URI, xác định phương thức HTTP (GET, POST, PUT, DELETE) và lắp ráp dữ liệu được cung cấp trong header hoặc trong URI.

Khi đã hoàn thành, lớp trừu tượng sẽ đưa các thông tin yêu cầu vào một phương thức trong lớp cụ thể để thực hiện công việc. Sau đó lớp này sẽ xử lý và trả về HTTP response cho client.

Ở khai báo trên, chúng ta trả về header các thông tin như: Access-Control-Allow-Origin (header chỉ định domain được phép truy cập), Access-Control-Allow-Methods (xác định phương thức được phép truy cập), Content-Type (kiểu dữ liệu, ở đây chúng ta trả về là json).

Chúng ta quan tâm đến hàm processAPI(). Công việc của nó là để xác định xem phương thức nào của lớp được thực thi khi nhận request từ phía client. Nếu có, nó sẽ gọi hàm được yêu cầu, nếu không sẽ trả về 404 response.Đó là tất cả những gì cho lớp trừu tượng. Bây giờ, chúng ta sẽ làm một lớp Concrete class.

Ở trên có 2 lớp APIKey và User mình không nhắc tới trong bài này nhưng nó sẽ được sử dụng cho ứng dụng API với namespace là Models, sẽ thực hiện các chức năng về API key và dữ liệu user.

Đơn giản là vậy, với mỗi endpoint bạn muốn trong API bạn có thể thêm giống như MyAPI class này cho phù hợp yêu cầu.

Để thực hiện các API chúng ta cần phải tạo ra các tập tin PHP mà trong file .htaccess mình đã cấu hình. Trong ví dụ này mình đặt tên nó chúng tôi :

Nếu bạn truy cập vào địa chỉ /api/v1/example (nếu có dữ liệu User và Token cần thiết) bạn sẽ thấy được kết quả.

Chào bạn,

I. Web service là gì?

Website thì ai cũng cũng biết rồi, như blog chúng tôi này chính là một website đó. Thế nhưng web service thì khác, không phải ai cũng có cơ hội được nghe thấy cụm từ này kể từ khi mà Restful trở nên phổ biến.

Web service cũng là một ứng dụng web hoạt động tương tự như một website, tức là để truy cập vào web service bạn cũng có thể mở trình duyệt lên, gõ vào thanh địa chỉ url của web service đó. Tuy nhiên khác với website – web để cho người đọc, thì web service sinh ra để cho các cỗ máy, hoặc các ứng dụng khác đọc.

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

Vậy là Quang tạo một trang web riêng cho Bình ở địa chỉ http://webtuyendungit.com/job-php, khi truy cập vào đây sẽ chỉ nhìn thấy nội dung khó hiểu 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 viên PHP không kinh nghiệm” }, ] }

Web service ra đời như là một điều hiển nhiên, bởi vì ngày càng có nhiều hệ thống chạy đa nền tảng như Facebook, Youtube,.. ra đời. Đặc điểm của các hệ thống chạy đa nền tảng này là luôn yêu cầu khả năng đồng bộ dữ liệu. Ví dụ bạn like một status facebook trên web, thì trên app cũng phải được thể hiện, bạn đăng một bức ảnh lên facebook từ mobile, thì trên web cũng phải nhìn thấy. Để làm được điều này, người ta sẽ tạo ra một con web service, để khi bạn đăng ảnh, like hay thực hiện bất kỳ hành động gì đều phải gọi tới web service này cho dù hành động đó được thực hiện từ web hay mobile. Mặt khác, ứng dụng web và mobile sẽ kết nối vào chung web service để đọc dữ liệu, vì vậy sẽ đảm bảo được dữ liệu là giống nhau cho dù trên các nền tảng khác nhau.

Tóm lại web service ra đời nhằm giải quyết một vấn đề sau

Đồng bộ dữ liệu giữa các nền tảng

Mỗi URL kèm HTTP method của web service thì được gọi là một endpoint, như ví dụ trên thì mình có http://webtuyendungit.com/job-php chính là một endpoint. Khi làm một endpoint cho web service, bạn sẽ phải quan tâm tới một số vấn đề sau:

Endpoint sử dụng cấu trúc dữ liệu nào để trả về?

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

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

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

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

http://webservice.com/users/1

Hoặc bạn có thể dùng một cách viết khác cũng được, nói chung là endpoint được viết như thế nào là do bạn, không có quy tắc chung nào cho cách viết endpoint cả.

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

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

An toàn dữ liệu

Web service trao đổi dữ liệu với các ứng dụng khác thông qua môi trường mạng. Nếu để lộ các endpoint, thì khả năng cao dữ liệu trả về trong các endpoint đó cũng bị lộ. Thực tế đã có rất nhiều vụ lộ thông tin người dùng mà 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 web service quá “tự do”, dữ liệu trả về, cách viết url, http method đều do bạn tự quyết định. Nhận thấy điều này không hợp lý, nên người ta đưa ra hai loại chuẩn cho web service như sau:

SOAP web 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 trúc dữ liệu trả về. Tuy nhiên SOAP không có quy ước về cách viết url cũng như http method. Nhưng bù lại, SOAP lại có WS-Security SOAP – là một chuẩn giúp an toàn dữ liệu, giải quyết được vấn đề an toàn dữ liệu mà mình đề cập ở trên.

RESTful web service

REpresentational State Transfer, là một chuẩn của web service. RESTful có thể sử dụng JSON, XML, plain text, html,.. làm cấu trúc dữ liệu trả về, có quy ước rõ ràng về cách viết url và http method. Nhưng RESTful không cung cấp cơ chế bảo vệ thông tin trong các endpoint như SOAP. Tuy nhiên bạn có thể sử dụng Json Web Token kết hợp với RESTful để giải quyết vấn đề này, nên việc không có sẵn cơ chế an toàn thông tin không phải là điều đáng lo ngại khi sử dụng RESTful.

SOAP vs RESTful

Ngày nay các dự án web service đa phần (thậm chí gần như tất cả) đều sử dụng RESTful thay vì sử dụng SOAP. Bởi như mình kể ra ở trên thì bạn thấy RESTful có quy ước rõ ràng hơn hẳn SOAP. Mặt khác RESTful có thể sử dụng nhiều loại dữ liệu để trả về, trong đó có cả XML, vậy xét ở góc độ nào đó có thể nói rằng RESTful bao gồm cả SOAP cũng không sai.

Tuy nhiên SOAP vẫn còn được sử dụng trong nhiều dự án cũ cần được bảo trì, nên bạn mà tìm hiểu được SOAP nữa thì càng tốt.

II. Tìm hiểu về RESTful

Bài viết viết về RESTful mà lại quá trời về web service. Mình trình bày như vậy là do theo đúng trình tự thì cái chúng ta biết trước phải là web service, sau đó mới là RESTful. Nhưng vì RESTful đang là một từ khóa hot, nên các bạn có xu hướng tìm hiểu về RESTful trước mà bỏ quên mất cái gốc web service.

RESTful có hệ thống quy tắc chặt chẽ về các viết endpoint và HTTP method, mình sẽ tóm tắt một vài nguyên tắc quan trọng làm nên “tên tuổi” của RESTful để bạn tiện theo dõi.

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

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

GET: được sử dụng để lấy thông tin từ sever theo URI đã cung cấp.

POST: gửi thông tin tới sever thông qua các biểu mẫu http (đăng kí chả hạn..)

HEAD: giống với GET nhưng response trả về không có body, chỉ có header

PUT: ghi đè tất cả thông tin của đối tượng với những gì được gửi lên

PATCH: ghi đè các thông tin được thay đổi của đối tượng.

DELETE: xóa tài nguyên trên server.

CONNECT: thiết lập một kết nối tới server theo URI.

OPTIONS: mô tả các tùy chọn giao tiếp cho resource.

TRACE: thực hiện một bài test loop – back theo đường dẫn đến resource.

Thực tế thì mình mới chỉ làm việc với các method GET, POST, PUT, DELETE thôi, các method còn lại thì chưa làm bao giờ, nhưng tương lai chắc là sẽ gặp :p.

2.2 Quy ước về resource, endpoint

Sử dụng danh từ để đặt tên cho resource

RESTful tổ chức resource dưới dạng các đối tượng, vì vậy resource nên được đặt tên dưới dạng dạng một danh từ chứ không phải một động từ. Giả sử mình có một số resource là: users, posts, thì resource tương ứng sẽ được viết trong các endpoint như sau:

http://api.example.com/users # Liệt kê tất cả user http://api.example.com/users/1 # Chi tiết user có ID là 1 http://api.example.com/posts # Liệt kê tất cả post http://api.example.com/posts/1 # Chi tiết post có ID là 1

Sử dụng đấu sượt (/) để thể hiện mối quan hệ phân cấp giữa các resources

Trong thực tế, các resource thường có mối quan hệ với nhau. Ví dụ mình có resource user, mỗi user lại có nhiều resource image. Thì minh có thể thiết kế các endpoint như sau

http://api.example.com/users # Liệt kê tất cả users http://api.example.com/users/1 # Chi tiết user có ID là 1 http://api.example.com/users/1/images # Liệt kê tất cả images của user có ID là 1

Dùng dấu gạch ngang (-) để ngăn cách giữa các cụm từ

http://api.example.com/banned-users # Tốt (1) http://api.example.com/banned_users # Không tốt (2) http://api.example.com/bannedUsers # Không tốt (3)

Trong ví dụ trên, cách (1) và (2) rõ ràng là dễ đọc hơn nhiều so với cách (3). Một số bạn theo chủ chương của camelcase có thể sẽ thấy cách (3) dễ đọc hơn. Tuy nhiên nếu mình có caiTenDaiNgoangNgoang thế này thì rõ ràng khó nhìn hơn cai-ten-dai-ngoang-ngoang thế này đúng không.

Vậy tại sao (1) lại tốt hơn (2)? Nguyên nhân là dâu gạch dưới (_) bị phụ thuộc nhiều vào font chữ hiển thị, trong một số trường hợp nó có thể bị che mất một phần, hoặc bị xóa, hoặc bị chuyển thành dấu cách trên một số trình duyệt. Điều này dễ dàng gây ra nhầm lẫn cho người sử dụng.

Sử dụng chữ thường 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, ngoại trừ phần giao thức và phần domain, thì các phần còn lại sẽ phân biệt chữ hoa chữ thường. Tức là ta có endpoint (1) sẽ tương tự với endpoint (2), nhưng endpoint (3) thì khác hoàn toàn.

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

Không sử 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 # không tốt (2) http://api.example.com/banned-users.xml # không tốt (3)

Đuôi mở rộng chính là .json và .xml trong endpoint (2) và (3) ở ví dụ trên. Một số bạn có thể thấy rằng như vậy là tường minh hơn, rằng khi tôi truyền .json nghĩa là tôi muốn lấy dữ liệu dạng json và tương tự với xml. Tuy nhiên làm như vậy không phải là cách hay vì:

Endpoint dài hơn và nhìn có vẻ xấu xí

Bạn sẽ phải bảo trì nhiều endpoint hơn

Nếu như bạn vẫn muốn endpoint có thể trả về nhiều kiểu dữ liệu khác nhau, thì bạn có thể sử dụng thuộc tính Content-Type của request header để xác định kiểu dữ liệu trả về.

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

Giả sử mình có một endpoint /users để lấy ra danh sách toàn bộ users. Nhưng thực tế mình chỉ muốn lấy ra các users ở Việt Nam. Một số bạn sẽ nghĩ đến cách tạo một endpoint như kiểu như /users/vn để giải quyết yêu cầu này. Tuy nhiên bạn không cần phải làm thế, chúng ta có thể coi Việt Nam như một tiêu chí để lọc, và endpoint nên được viết như thế này

http://api.example.com/users?country=vn # tốt. Sử dụng query params country http://api.example.com/users/vn # không tốt

Bạn cũng nên sử dụng query params để phân trang hoặc sắp xếp kết quả thay vì việc thiết kế một endpoint mới

http://api.example.com/users?page=1 # Tốt http://api.example.com/users/pages/1 # Không tốt http://api.example.com/users?orderBy=latest # Tốt http://api.example.com/users/orderBy/latest # Không tốt http://api.example.com/users/orderBy?latest # Không tốt

Sử dụng HTTP method để thể hiện CRUD

Bạn không nên thể hiện các thao tác với resource bằng việc chỉ ra trên URI, thay vào đó bạn hãy sử dụng các HTTP method tương ứng.

# Liệt kê danh sách users HTTP GET http://api.example.com/users # Nên HTTP GET http://api.example.com/users/all # Không nên # Thêm một users mới vào danh sách HTTP POST http://api.example.com/users # Nên HTTP POST http://api.example.com/users/create # Không nên HTTP POST http://api.example.com/users/store # Không nên # Cập nhật thông tin user có ID là 1 HTTP PUT http://api.example.com/users/1 # Nên HTTP POST http://api.example.com/users/1/update # Không nên HTTP POST http://api.example.com/users/1/edit # Không nên # Xóa user có ID là 1 HTTP DELETE http://api.example.com/users/1 # Nên HTTP POST http://api.example.com/users/1/destroy # Không nên HTTP POST http://api.example.com/users/1/delete # Không nên

2.3 Có nhất thiết phải tuân theo 100% chuẩn RESTful không?

Thực tế mình trải qua các dự án sử dụng RESTful thì chưa có dự án nào thực hiện được 100% chuẩn của RESTful, bởi

Đa phần các developer chỉ thích dùng method POST và GET cho đơn giản

Một số ý kiến cho rằng khó sử dụng hơn

Tập trung vào RESTful không làm cho sản phẩm chạy tốt hơn, chỉ làm cho code đẹp hơn, tuy nhiên một số trường hợp thì code đẹp không cần thiết.

Vậy có nhất thiết là phải chuẩn 100% RESTful không? Câu trả lời là không, chuẩn của RESTful là một chuyện nhưng nó cũng phải phù hợp với sự thống nhất của team, phù hợp với tính chất của dự án. Nhưng quan điểm của mình là càng chuẩn RESTful thì càng tốt.

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

3.1. API là gì?

Vì một phần mềm chứa rất nhiều logic phức tạp, nên người ta tìm cách chia nhỏ nó ra thành nhiều phần, mỗi phần này tạm gọi là một component. Mỗi component sẽ có tính độc lập cao, ít phụ thuộc hoặc có thể không phục thuộc vào các thành phần khác. Tuy là có tính độc lập cao, nhưng để có thể kết nối được với nhau mà một phần mềm hoàn chỉnh, buộc chúng vẫn phải tuân theo một hoặc một số chuẩn nào đó. Thì mỗi cái chuẩn đó được gọi là một giao diện lập trình ứng dụng – hay chính là một API.

3.2 RESTful API là gì?

RESTful API là những API của web service sử dụng theo chuẩn RESTful. Trước khi áp dụng RESTful để tạo API, người ta sẽ đưa ra các chuẩn (API) trước. Ví dụ mình quy định nếu thực hiện thêm users thành công, thì sẽ phải trả về header status là 200, kèm một tin nhắn có nội dung là “thành công” chẳng hạn, ai mà làm sai theo quy tắc này tức là sai API, và 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 muốn bạn lưu một số ý chính sau:

RESTful chỉ là một chuẩn của web service, muốn biết về RESTful thì phải tìm hiểu về web service trước.

RESTful không khó, nó chỉ là một tập các quy tắc thôi, tuân theo quy tắc này tức là bạn đã làm được RESTful

Bài viết được viết dựa trên kinh nghiệm làm việc của mình và tham khảo một số nguồn. Xin nhận mọi gạch đá.

(*) CURL: là bộ thư viện được sử dụng để giúp thực hiện việc chuyển dữ liệu thông qua nhiều giao thức khác nhau như HTTP, FPT…

Là một lập trình viên; Thích tìm hiểu và chia sẻ kiến thức công nghệ; Thích chiêm nghiệm cuộc sống

Ngày trước khi chưa biết tới WordPress REST API, mình thường tạo 1 page /api và viết API cho WordPress. Việc đó khá tốn thời gian, công sức và nhiều khi không được như ý. Còn bây giờ với WordPress REST API, mọi thứ dường như đã dễ dàng hơn khá nhiều. Mình sẽ chia sẻ lại nhưng kinh nghiệm sau khi trải nghiệm với WordPress REST API.

WordPress REST API là gì?

WordPress REST API cung cấp API Endpoint cho phép các lập trình viên tương tác với các trang web từ xa bằng cách gửi và nhận các đối tượng JSON (Ký hiệu đối tượng JavaScript). JSON là một định dạng dữ liệu tiêu chuẩn mở, nhẹ và dễ đọc. Khi bạn gửi nội dung đến hoặc đưa ra yêu cầu tới API, phản hồi sẽ được trả về ở định dạng JSON. Điều này cho phép các lập trình viên tạo, đọc và cập nhật nội dung WordPress từ xa hoặc từ các ứng dụng bên ngoài.

Các khái niệm của WordPress REST API

Để bắt đầu, bạn cần hiểu các khái niệm sau:

Routes/Endpoints: Có thể hiểu đây là đường dẫn nới bạn gửi request tới trên blog của bạn. Nó có đường dẫn là: http://your-blog.com/wp-json/

Requests: Yêu cầu gửi tới Endpoint

Responses: Dữ liệu trả về của Endpoin

Schema: Cấu trúc dữ liệu mà Responses trả về để bạn có thể xác định được dữ liệu cần tìm

Controller Classes: Trình điều khiển, nơi quản lý, điều hướng Endpoint, Request, Responses

Hướng dẫn sử dụng WordPress REST API

Bây giờ chúng ta sẽ cùng tìm hiểu cách quản lý WordPress thông qua WordPress REST API

Đường dẫn base là:

http://your-blog.com/wp-json curl -X OPTIONS -i http://your-blog.com/wp-json/wp/v2/posts

Liệt kê danh sách trang (pages)

curl -X GET -i http://your-blog.com/wp-json/wp/v2/pages

Lấy bài viết theo ID

Để tạo 1 bài viết mới trong WordPress, thông thường bạn phải login vào trang quản trị và viết bài. Tuy nhiên với Rest API bạn không thể login bằng phương pháp thông thường. Vì vậy bạn cần 1 plugin để thực hiện điều đó mới có thể tạo bài viết thông qua REST API. Đó là Basic Auth

Sau khi cài đặt xong chúng ta có thể tạo bài viết với xác thực đơn giản:

curl –user username:password http://your-blog.com/wp-json/

Hoặc tạo bài viết với phần header:

Authorization: Basic dGVzdHVzZXI6MTIzNDU2

Với: dGVzdHVzZXI6MTIzNDU2 là mã base64 của username:password

Xóa bài viết

Kết luận

Bên trên là một số ví dụ về sử dụng WordPress REST API để quản lý bài viết, ngoài ra còn có rất nhiều tính năng khác. Các bạn vui lòng tham khảo tài liệu chính thức ở đây.

Nguồn: vinasupport.com

Cập nhật thông tin chi tiết về Api Là Gì Trong Java / 2023 trên website Ezlearning.edu.vn. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung để bạn nhận được thông tin nhanh chóng và chính xác nhất. Chúc bạn một ngày tốt lành!

Xu Hướng 11/2022 # Api Là Gì Trong Java / 2023 # Top 17 View | Ezlearning.edu.vn

mtoplist