Khái niệm cơ bản về phát triển API REST và RESTful

Các nhà phát triển web thường xuyên nói về Nguyên tắc REST và kiến ​​trúc dữ liệu RESTful, vì đó là một khía cạnh quan trọng của sự phát triển hiện đại, nhưng đôi khi nó có thể gây nhầm lẫn vô cùng. Bản thân REST không phải là một công nghệ, mà là một phương pháp tạo API với các nguyên tắc tổ chức nhất định. Các nguyên tắc này là để hướng dẫn các nhà phát triển và tạo một môi trường phổ quát hơn để xử lý các yêu cầu API.

Trong bài đăng này, tôi muốn giải thích các thực tiễn phát triển RESTful từ góc nhìn của một con chim. Tôi muốn giải quyết các gì hơn là làm sao. Mặc dù tôi sẽ chạm vào cả hai lĩnh vực, bài đăng này được tạo cho bất kỳ ai tham gia phát triển web, nhưng đơn giản là không thể nắm bắt được khái niệm về API REST.

REST dành cho nhà phát triển web

Từ viết tắt REST là viết tắt của chuyển trạng thai biểu hiện. Điều này nghe có vẻ khó hiểu và mục wiki làm cho nó nghe có vẻ khó hiểu hơn. Nhưng có thể đơn giản hóa thuật ngữ.

REST chỉ là một chuỗi hướng dẫn và phong cách kiến ​​trúc được sử dụng để truyền dữ liệu. Nó thường được áp dụng cho các ứng dụng web, nhưng cũng có thể truyền dữ liệu cho phần mềm.

API từ viết tắt của Giao diện lập trình ứng dụng, là các phương thức kết nối với các thư viện hoặc ứng dụng khác. Windows có nhiều API và Twitter cũng có API web, mặc dù chúng thực hiện các nhiệm vụ khác nhau với các mục tiêu khác nhau.

Kết hợp tất cả lại với nhau, API RESTful là các API tuân theo kiến ​​trúc REST.

Chính xác kiến ​​trúc REST là gì?

Đây là nơi khó khăn để đặt chi tiết cụ thể. Tuy nhiên, có một số hằng số kiến ​​trúc, chẳng hạn như:

• Tính nhất quán trên toàn bộ API
• Sự tồn tại không quốc tịch, tức là không có phiên phía máy chủ
• Sử dụng Mã trạng thái HTTP nơi thích hợp
• Sử dụng Điểm cuối URL với hệ thống phân cấp logic
• Phiên bản trong URL thay vì trong các tiêu đề HTTP

Không có bất kỳ hướng dẫn cụ thể quá mức nào như thông số HTML5 của W3C có thể dẫn đến nhầm lẫn và một vấn đề không chắc chắn về thuật ngữ REST.

Ngoài ra, danh sách trên không nên được coi là quy tắc khó và nhanh, mặc dù chúng đúng với hầu hết các API RESTful hiện đại.

REST là một phương pháp học nhẹ mà làm cho nó hoàn hảo cho dữ liệu HTTP. Đây là lý do tại sao REST trở nên phổ biến trên web và tại sao nó được coi là lựa chọn tốt nhất để phát triển API.

Như Vinay Sahni nói, “API là giao diện người dùng của nhà phát triển.” Mọi thứ nên dễ sử dụng và cung cấp trải nghiệm người dùng tuyệt vời. API RESTful nhằm mục đích làm điều đó.

Các bước chính cho API RESTful

Những mẹo này nằm trong ngữ cảnh của API nghiêm ngặt cho các ứng dụng web. Điều này có nghĩa rằng HTTP là một yêu cầu, và nó thường có nghĩa là dữ liệu API được lưu trữ trên một máy chủ bên ngoài. Hãy xem xét cách các API RESTful hoạt động về phía người dùng API.

Người dùng API là nhà phát triển web có thể xây dựng tập lệnh kết nối với máy chủ API bên ngoài, sau đó dữ liệu cần thiết được truyền qua HTTP. Sau đó, nhà phát triển có thể hiển thị dữ liệu trên trang web của họ không có quyền truy cập cá nhân vào máy chủ bên ngoài (như lấy dữ liệu Twitter).

Nói chung là có bốn lệnh đã từng truy cập API RESTful:

1. ĐƯỢC để lấy một đối tượng
2. BÀI ĐĂNG để tạo một đối tượng mới
3. ĐẶT để sửa đổi hoặc thay thế một đối tượng
4. XÓA BỎ để loại bỏ một đối tượng

Mỗi phương pháp nên thông qua lệnh gọi API nói cho máy chủ biết phải làm gì.

Phần lớn các API web chỉ cho phép ĐƯỢC yêu cầu để kéo dữ liệu từ một máy chủ bên ngoài. Xác thực là tùy chọn, nhưng chắc chắn là một ý tưởng tốt khi cho phép các lệnh có khả năng gây hại như ĐẶT hoặc là XÓA BỎ.

Tuy nhiên, không có nhiều API RESTful thậm chí còn đi xa đến thế. Hãy xem xét Pokéapi là cơ sở dữ liệu API Pokémon miễn phí. Nó mở cửa cho công chúng với giới hạn tỷ lệ khá (giới hạn người dùng ở một số yêu cầu API nhất định trong một khoảng thời gian), nhưng chỉ cho phép ĐƯỢC phương pháp truy cập tài nguyên. Điều này có thể được gọi là thông tục API chỉ tiêu thụ.

Trả về các loại cũng quan trọng và nên giữ sự đồng nhất cho tất cả các nguồn lực. JSON là một kiểu trả về phổ biến với thông số kỹ thuật trực tuyến giải thích các cấu trúc dữ liệu phù hợp.

API RESTful sử dụng danh từ cho các đối tượng API, và động từ để thực hiện hành động trên các đối tượng đó. Xác thực có thể là một phần của điều này, giới hạn tỷ lệ cũng có thể là một phần của điều này. Nhưng một API rất đơn giản có thể nhận được mà không cần quan tâm nhiều đến các giới hạn của người dùng.

Truy cập tài nguyên API

API công khai thường có thể truy cập từ các địa chỉ trang web trực tiếp. Điều này có nghĩa là cấu trúc URL rất quan trọng, và chỉ nên được sử dụng cho các yêu cầu API.

Một số URL có thể bao gồm một thư mục tiền tố như / v2 / cho phiên bản cập nhật 2 của API trước đó. Điều này là phổ biến đối với các nhà phát triển không muốn khấu hao API 1.x của họ, nhưng vẫn muốn cung cấp cấu trúc mới nhất.

Tôi thực sự rất thích bài này cấu trúc URL cơ bản và ví dụ từ các dịch vụ khác.

Lưu ý rằng điểm cuối của dữ liệu trả về sẽ thay đổi đáng kể dựa trên Phương thức HTTP. Ví dụ, ĐƯỢC lấy nội dung, trong khi BÀI ĐĂNG tạo nội dung mới. Yêu cầu có thể trỏ đến cùng một điểm cuối, nhưng kết quả có thể rất khác nhau.

Nhìn qua các ví dụ trực tuyến có thể giúp bạn hiểu các khái niệm rõ ràng hơn. Chúng tôi đã thấy Pokeapi, nhưng đây là một số khác ví dụ API trong thế giới thực để xem xét:

• API Reddit
• API GitHub
• API Flickr
• API Pinterest

Xây dựng API của riêng bạn

Quá trình xây dựng API của riêng bạn không nên xem nhẹ nhưng nó cũng không phức tạp như bạn nghĩ. Nó có một hiểu biết về các mẫu thiết kế API và các thực tiễn tốt nhất để xây dựng một cái gì đó có giá trị thực sự.

Mỗi API phải kết nối với máy chủ của bạn để trả về dữ liệu của một số loại. Bạn không chỉ cần viết mã để làm điều đó, mà bạn còn cần định dạng dữ liệu trả về. Các yêu cầu tiềm năng khác bao gồm xác thực và giới hạn tỷ lệ, Vì vậy, việc xây dựng một API chắc chắn không dành cho người yếu tim.

Nhưng hãy xem một số nguyên lý cơ bản của kiến ​​trúc API.

Xây dựng điểm cuối

Một khía cạnh của phát triển API là xây dựng điểm cuối. Khi nào tạo tài nguyên bạn muốn sử dụng danh từ, không phải động từ. Điều này có nghĩa là dữ liệu API sẽ trả về một người, địa điểm hoặc vật, thường xuyên nhất là một điều với các thuộc tính cụ thể (ví dụ một tweet và tất cả siêu dữ liệu của nó).

Có thể khó học cách đặt tên cho danh từ, nhưng đây là khía cạnh quan trọng của phát triển API. Đơn giản hóa là tốt nhất bất cứ khi nào có thể.

Một cuộc tranh luận lớn là số ít so với số nhiều danh từ Nếu bạn đang tạo API Twitter, trước tiên bạn có thể có nhóm đối tượng (nghĩa là tweet), sau đó là mục đối tượng thứ hai (ví dụ: ID tweet).

 $ / tweet / 15032934882934 $ / tweet / 15032934882934 

Trong trường hợp này, tôi cho rằng hình thức số ít có vẻ tốt hơn. Điều này đúng đặc biệt khi chỉ có một tài nguyên được trả về. Nhưng không có câu trả lời đúng 100%, vì vậy hãy làm bất cứ điều gì phù hợp nhất với dự án của bạn.

Đặt loại trả về

Một cân nhắc khác là trả về loại dữ liệu. Hầu hết người dùng web mong đợi nội dung JSON, vì vậy đó có thể là lựa chọn tốt nhất. XML là một lựa chọn khác nếu bạn muốn cung cấp cả hai. Tuy nhiên JSON là loại trả về API cơ bản giữa các nhà phát triển web.

Có nhiều thứ nữa đi vào phát triển API, vì vậy tôi khuyên bạn nên chơi với API trước. Bằng cách này, bạn có thể thấy cách các nhà phát triển khác xây dựng API của họ và hy vọng bạn sẽ làm quen với các yêu cầu điển hình.

Nếu bạn mới bắt đầu, vui lòng xem xét lướt qua các hướng dẫn dành cho nhà phát triển này:

• Trang web hướng dẫn API REST
• Viết API REST đơn giản
• Xây dựng một dịch vụ web RESTful

Tài nguyên khác

Cách tốt nhất để học phát triển ứng dụng web là thông qua thực hành. Lý thuyết được cấp luôn luôn đáng để nghiên cứu, bởi vì nó cho phép bạn trò chuyện với các nhà phát triển và hiểu cách mọi thứ hoạt động.

Nhưng một nơi tốt để bắt đầu phát triển API là kết nối với các API khác Đầu tiên. Tìm hiểu kiến ​​thức cơ bản về kết nối phía máy khách và từ đó bạn có thể chuyển sang phát triển API phía máy chủ bằng cách tạo API của riêng bạn từ đầu.

Nếu đó là mục tiêu của bạn, vui lòng xem xét các tài nguyên sau để trợ giúp trong hành trình của bạn.

Sách

• Quy tắc thiết kế API REST
• API Web RESTful
• Dịch vụ web RESTful Cookbook
• REST không bị xáo trộn: Hướng dẫn thiết kế API hoàn hảo

Bài viết

• Hướng dẫn cho người mới bắt đầu về HTTP và REST
• Tạo API RESTful
• Hướng dẫn đặt tên tài nguyên RESTful
• Tạo API REST bằng MEAN Stack