Lập trình/Tìm hiểu về web service và API/

Tìm hiểu về web service và API

Trước khi đọc bài viết, bạn hãy lưu ý rằng bài viết nói về high-level của Web Service API, nghĩa là về bản chất của API, không viết về cách code.

Để hiểu rõ hơn về RESTful API ta sẽ đi lần lượt giải thích hai khái niệm nhở API, REST hay RESTful.

API là gì?

API là viết tắt của Application Programming Interface, là nền tảng kết nối hai hay nhiều process máy tính (hay gọi là máy tính) liên lạc, trao đổi thông tin với nhau.

REST là gì?

REST (REpresentational State Transfer) là một dạng chuyển đổi cấu trúc dữ liệu. Nó sử dụng phương thức HTTP đơn giản để tạo cho giao tiếp giữa các máy. REST gửi một yêu cầu HTTP như GET, POST, DELETE, vv đến một URL để xử lý dữ liệu.

RESTful API là tiêu chuẩn dùng trong việc thiết kế các API, quy định cách sử dụng các HTTP method (như GET, POST, PUT, DELETE…) hoặc status code trả về từ các máy.

Tiêu chuẩn HTTP method trong REST

REST hoạt động chủ yếu dựa vào giao thức HTTP. Các hoạt động cơ bản nêu trên sẽ sử dụng những phương thức HTTP riêng.

  • GET (SELECT): “hiển thị” một hoặc nhiều item
  • POST (CREATE): Tạo mới
  • PUT (UPDATE): Cập nhật toàn phần
  • PATCH (UPDATE: Cập nhật một phần
  • DELETE (DELETE): Xoá

Meta data loại JSON thường được sử dụng nhiều hơn vì độ thân thiện dữ liệu của chúng. Trong khi đó, SOAP API lại hay được trong những hệ thống lớn, đã chạy lâu năm.

Tiêu chuẩn Status code trong REST

Khi chúng ta request một API nào đó thường thì sẽ có vài status code để nhận biết sau:

Status code 2xx (thành công)

Khi request thành công mà không gặp mất kì lỗi nào.

  • 200 OK – Trả về thành công cho những phương thức GET, PUT, PATCH hoặc DELETE.
  • 201 Created – Tạo mới một dữ liệu
  • 204 No Content – Không có dữ liệu nào được trả về

Status code 3xx (điều hướng)

Server phải thực hiện hành động bổ sung để hoàn thành request.

  • 301 – Permanent Redirect – chuyển hướng hoàn toàn
  • 302 – Temporarily Redirect – chuyển hướng tạm thời
  • 304 Not Modified – Trả về từ cache

Status code 4xx (lỗi người dùng)

Lỗi này thường về phía người dùng (người sử dụng browser hay khách viếng thăm website).

  • 400 Bad Request – Request không hợp lệ
  • 401 Unauthorized – Request không có bảo mật
  • 403 Forbidden – Không được phép truy cập
  • 404 Not Found – Không tìm thấy bất kì thông tin nào
  • 405 Method Not Allowed – Phương thức (GET, POST, PUT, PATCH, DELETE) không cho phép
  • 415 Unsupported Media Type – Không hỗ trợ kiểu Resource này.
  • 422 Unprocessable Entity – Dữ liệu không được xác thực
  • 429 Too Many Requests – Request bị từ chối do bị giới hạn

Status code 5xx (lỗi server)

Lỗi này. thuộc về phía máy chủ, có thể đến từ code, tràn bộ nhớ, hết dung lượng, DDOS,…

  • 500 – Internal Server Error – Hư
  • 501 – Not implement – Chưa code
  • 502 – Bad Gateway – đa số là do lỗi server (Nginx, Apache, Lite Speed,…)
  • 503 – Service Unavailable – Server tạm thời không xử lý được/ kịp

Ví dụ về API

Ví dụ về request – response trong API

Khi bạn sử dụng một ứng dụng trên điện thoại di động, ứng dụng kết nối Internet và gửi dữ liệu tới máy chủ. Máy chủ sau đó lấy ra dữ liệu đó, diễn giải nó, thực hiện các hành động cần thiết và gửi nó trở lại điện thoại của bạn. Ứng dụng sau đó giải thích dữ liệu đó và trình bày cho bạn thông tin bạn muốn theo cách có thể đọc được. Đây là những gì một API là – tất cả điều này xảy ra thông qua API.

Trước khi đến với khái niệm chuyên môn, chúng ta hãy lấy một ví dụ quen thuộc. Hãy tưởng tượng bạn đang ngồi trong nhà hàng và chuẩn bị đặt món. Đầu bếp – “hệ thống” sẽ nấu thức ăn cho bạn. Cái còn thiếu là liên kết giữa bạn và đầu bếp ấy. Bạn không có khả năng biết bếp là khu nào trong nhà hàng để xông thẳng vào và gọi món.Đó là lúc bạn cần đến người phục vụ – API.

Người bồi bàn này sẽ là người bồi bài, (hay thông thường chúng ta thường gọi là request – yêu cầu) của bạn nói với đầu bếp biết phải làm gì. Người đầu bếp – “hệ thống” biết phải nấu cho bạn cái gì và đưa cho người bồi bàn sau khi đã hoàn thành. Sau đó, người bồi bàn này sẽ mang thứ bạn cần – thức ăn/ thông tin (hay chúng ta hay gọi là response).

Ví dụ về mối quan hệ giữa API về web service

Bạn có thể đã quen thuộc với quá trình tìm kiếm các chuyến bay trực tuyến. Cũng giống như nhà hàng, bạn có nhiều lựa chọn để lựa chọn, bao gồm các thành phố khác nhau, ngày khởi hành và ngày trở lại, và nhiều hơn nữa.Hãy tưởng tượng bạn đang đặt phòng bạn đang bay trên một trang web của hãng hàng không. Bạn chọn một thành phố, ngày khởi hành, ngày về, hạng ghế,…Để đặt chuyến bay của bạn, bạn tương tác với trang web của hãng hàng không để truy cập vào cơ sở dữ liệu của họ và xem liệu có ghế nào phù hợp với nhu cầu của bạn và chi phí là bao nhiêu.

Tuy nhiên, nếu bạn không sử dụng trang web trực tiếp hãng hàng không như vietnamairlines để mua vé thì mà sử dụng dịch vụ thứ ba như Traveloka hoặc Booking? Nó có sự khác biệt?

Câu trả lời là có.

Khi bạn mua vé trên web chính thống của Vietnamairlines, vé bạn mua sẽ được tương tác trực tiếp với dữ liệu, database của hãng. Trong khi đó, nếu mua tại Traveloka, hoặc Booking, họ sẽ thay mặt chúng ta gửi yêu cầu đến API của Vietnamairlines, nhận dữ liệu về (response) và hiển thị thông tin cho chúng ta.Nói cách khác, Traveloka và Booking ở đây đóng vai trò là cầu nối cho khách hàng (chúng ta) được tiếp cận với dữ liệu của Vietnamairlines.

Những gì API cung cấp cũng là một lớp bảo mật. Dữ liệu điện thoại của bạn không bao giờ được tiếp xúc hoàn toàn với máy chủ. Tương tự, máy chủ không bao giờ được phơi bày hoàn toàn với điện thoại của bạn. Thay vào đó, mỗi giao tiếp (communication) với các gói dữ liệu nhỏ (packet), chỉ chia sẻ những thứ cần thiết – giống như đặt hàng. Bạn nói với nhà hàng/ traveloka/ booking những gì bạn muốn ăn, muốn đặt chỗ, họ nói cho bên cung cấp biết những gì bạn cần và cho bạn những gì bạn muốn.

Web service là gì?

Nói đơn giản, web service là một lớp (framework) giữa hai máy tính, giúp hai máy tính có thể tương tác với nhau qua mạng. Nói cách khác, web service cho phép một chương trình máy tính có thể nói chuyện với một trang web thay vì người dùng tự dùng trình duyệt để truy cập trang web.

web service

Một mô hình để thể hiện sự kết nối này: client (người dùng – máy tính 1) gửi tin nhắn đến server (máy chủ – máy tính 2) và server hồi âm lại tin nhắn đó nhờ có web service. Web service hiện nay đa số giao tiếp qua cơ chế HTTP, nhưng format dữ liệu khi gửi và nhận thì hoàn toàn khác nhau.

Vậy là Stream Hub đã giải thích xong về Web service, API và REST là gì rồi. Nếu tò mò thêm về cách tạo nên một web service, các bạn hãy tìm đọc bài tiếp theo về cách cài framework nodejs.

Hướng dẫn cài đặt NodejsHướng dẫn triển khai website chạy Nodejs lên VPSDomain Name System là gì

Mai Nguyên Vũ

Cái blog củ cải của một bạn đang tập ăn nhiều cá và rau.

  • Chúng tôi ở đâu

    33 Đặng Thai Mai, Phường 7, Phú Nhuận, Thành phố Hồ Chí Minh

  • Thời gian hoạt động

    8:30 - 18:00 T2 đến T7

Giới thiệu | Chính sách bảo mật | Liên hệ