Bạn đã bao giờ tự hỏi Facebook, Grab, Shopee giao tiếp với nhau như thế nào? Bí mật nằm ở API! Video này sẽ giải thích API là gì một cách dễ hiểu nhất, ngay cả khi bạn không phải là dân công nghệ. Chúng ta sẽ khám phá các khái niệm cơ bản như REST API, HTTP methods (GET, POST, PUT, DELETE, PATCH), Endpoint, JSON, Authentication, Authorization, API Key, Rate limiting, RESTful API, Status code, CRUD operations, Query parameters, Path parameters, Idempotent, HATEOAS, Versioning API, Content negotiation, OAuth 2.0, JWT, CORS, API Gateway, HTTPS, SQL Injection, Input validation, API throttling, Bearer token, Refresh token, GraphQL, Schema, Query, Mutation, Resolver, Over-fetching, Under-fetching, Integration testing, Postman, Contract testing, Mock API, Load testing API, API documentation, Swagger/OpenAPI, Webhooks, Pagination, Caching, ETag, Circuit breaker pattern, API rate limit, Microservices architecture, Service mesh, API versioning strategies, Deprecation policy, Batch requests, Long polling, WebSocket, API proxy, BFF, API composition, Idempotency key, API monitoring, Blue-green deployment, Canary deployment, API health check endpoint, Logging, Compression, Hypermedia controls, Content-Type header, API sandbox environment, Partial response, ETL, Serverless, gRPC, API federation, Schema validation, API analytics, Middleware, Rate limiting strategies, Mutual TLS, API payload encryption, Webhook security, API deprecation header, Consumer-driven contracts và nhiều hơn nữa! Hãy cùng Giải Mã Công Nghệ khám phá sức mạnh của API và cách nó thay đổi thế giới công nghệ xung quanh ta.
Chào mừng các bạn đã đến với “Giải mã công nghệ” – nơi chúng ta biến những khái niệm khô khan thành những câu chuyện vui vẻ, dễ hiểu! Hôm nay, chúng ta sẽ cùng nhau khám phá một “người hùng thầm lặng” nhưng cực kỳ quyền lực trong thế giới công nghệ: API! Nghe tên thì hơi “hàn lâm” đúng không? Nhưng yên tâm, sau video này, bạn sẽ thấy API thân thiện hơn cả đứa bạn thân hay mượn tiền mà không trả của bạn ấy!
Tưởng tượng thế này: bạn đang đói meo, muốn ăn một tô phở. Bạn không tự vào bếp làm từ A đến Z, mà bạn đến một quán phở, gọi món. Quán phở sẽ chuẩn bị cho bạn. Trong kịch bản này, bạn là “ứng dụng” của mình, tô phở là “dữ liệu” bạn muốn, và cô bán phở chính là… API!
Vậy thì, API là gì? Nó là viết tắt của Application Programming Interface – giao diện lập trình ứng dụng. Nghe tên đã thấy “sờ-mát” rồi đúng không? Đơn giản hơn, API là một “cầu nối”, một “người phiên dịch” giúp các ứng dụng khác nhau nói chuyện với nhau. Khi bạn dùng Facebook, đặt Grab, hay xem dự báo thời tiết, bạn đang tương tác với API đó! Nó hoạt động bằng cách nhận yêu cầu (request) từ ứng dụng của bạn và trả về phản hồi (response) theo một định dạng chuẩn. Giống như cô bán phở nhận yêu cầu “một phở tái, không hành” và trả về tô phở đúng ý bạn vậy!
Nhưng khoan, có người sẽ hỏi: “Thế API với Web Service khác nhau chỗ nào ạ?” À, câu hỏi hay! Hãy hình dung Web Service là một loại API đặc biệt, chuyên dùng để giao tiếp qua mạng internet, giống như bạn gọi điện thoại đặt phở vậy. Còn API thì rộng hơn, nó có thể là cách các phần mềm trong một máy tính nói chuyện với nhau, hoặc thậm chí là cách các linh kiện phần cứng giao tiếp. Tóm lại, mọi Web Service đều là API, nhưng không phải mọi API đều là Web Service. Giống như mọi con chó đều là động vật, nhưng không phải mọi động vật đều là chó vậy! Hiểu chưa nào?
Tiếp theo, chúng ta sẽ làm quen với một loại API cực kỳ phổ biến: REST API! REST là viết tắt của Representational State Transfer. Nghe tên đã thấy “chất” rồi đúng không? REST API giống như một bộ quy tắc giao tiếp lịch sự, hiệu quả trên internet, chủ yếu sử dụng các phương thức HTTP và giao tiếp “stateless” – nghĩa là server không cần nhớ bạn là ai giữa các lần yêu cầu, mỗi lần yêu cầu phải độc lập và đầy đủ thông tin. Cứ như bạn đến quán phở, lần nào cũng phải gọi lại món chứ cô bán phở không nhớ hôm trước bạn ăn gì đâu!
Mà nhắc đến HTTP methods, đó là gì nhỉ? Đơn giản là những “động từ” bạn dùng để nói chuyện với API.
GET: “Cho tôi xem dữ liệu này!” (Giống như nhìn menu).
POST: “Tôi muốn tạo cái này!” (Giống như gọi món phở mới).
PUT: “Tôi muốn thay đổi toàn bộ cái này thành cái mới!” (Giống như đổi sang tô phở khác hoàn toàn).
PATCH: “Tôi muốn thay đổi một phần nhỏ của cái này!” (Giống như thêm tí tương ớt vào tô phở).
DELETE: “Xóa cái này đi!” (Giống như trả lại tô phở không ăn nữa).
Đấy, dễ hiểu chưa!
Vậy còn Endpoint trong API là gì? Endpoint là địa chỉ cụ thể mà bạn gửi yêu cầu đến để thực hiện một hành động nào đó. Ví dụ, nếu bạn muốn xem danh sách bạn bè trên Facebook, bạn sẽ gửi yêu cầu đến một endpoint kiểu như api.facebook.com/users/friends. Nó giống như địa chỉ của quán phở mà bạn phải đến để gọi món vậy.
Rồi, khi API trả lời, nó thường dùng định dạng JSON. JSON (JavaScript Object Notation) là một định dạng dữ liệu cực kỳ phổ biến. Nó giống như một danh thiếp nhỏ gọn, dễ đọc, dễ hiểu, được cấu trúc rõ ràng. “Anh tên là Nguyễn Văn A, sinh năm 1990, nghề nghiệp: Developer, sở thích: ăn phở.” Dễ đọc hơn nhiều so với một bài văn dài dòng đúng không? Đó là lý do JSON được yêu thích trong API!
Này, bạn có thấy nhiều trang web yêu cầu đăng nhập không? Đó là Authentication trong API đấy! Authentication là quá trình xác minh danh tính của bạn. “Bạn là ai?” Bạn phải đưa ra chứng minh thư, thẻ sinh viên, hoặc mật khẩu để API biết bạn là người hợp lệ.
Thế thì Authorization khác Authentication như thế nào? Authentication là “Bạn là ai?”, còn Authorization là “Bạn được phép làm gì?”. Ví dụ, bạn có thẻ sinh viên (authentication), nhưng bạn chỉ được vào thư viện chứ không được vào phòng hiệu trưởng (authorization). API cũng vậy, bạn đăng nhập (authentication) nhưng chỉ được truy cập vào những dữ liệu mà bạn có quyền (authorization).
Để đơn giản hóa quá trình xác thực, đôi khi API dùng API Key. Nó giống như một cái thẻ chìa khóa riêng biệt mà bạn dùng để mở cửa. Mỗi lần gửi yêu cầu, bạn đính kèm cái key này vào để API biết bạn là ai.
Đã bao giờ bạn thử làm mới trang web liên tục, và đột nhiên nó báo lỗi “Too Many Requests” không? Đó là Rate limiting trong API đấy! API có một “giới hạn tốc độ” để bảo vệ server khỏi bị quá tải. Giống như một quán phở chỉ có thể phục vụ 100 tô mỗi giờ thôi, bạn không thể ép họ làm 1000 tô được!
Chúng ta đã nói về REST API, vậy một RESTful API cần tuân thủ những nguyên tắc nào để được gọi là “RESTful” chuẩn chỉnh?
1. Stateless: Server không lưu trạng thái của client. Mỗi request là độc lập.
2. Client-server architecture: Client và server tách biệt nhau.
3. Cacheable: Có thể lưu trữ tạm thời các phản hồi để tăng tốc.
4. Uniform interface: Các endpoint nên có cách gọi nhất quán.
5. Layered system: Có thể có nhiều lớp trung gian (proxy, load balancer) mà client không biết.
Cứ như một nhà hàng chuyên nghiệp vậy, mọi thứ phải rõ ràng, hiệu quả!
Khi bạn gửi request đến API, nó sẽ trả về một Status code. Đây là những mã số báo hiệu kết quả của yêu cầu của bạn.
2xx (Thành công): “Tuyệt vời, yêu cầu của bạn đã được xử lý!” (200 OK, 201 Created)
3xx (Redirect): “Không ở đây, thử chỗ khác nhé!” (301 Moved Permanently)
4xx (Lỗi Client): “Lỗi là do bạn đó, kiểm tra lại yêu cầu đi!” (400 Bad Request, 404 Not Found, 401 Unauthorized)
5xx (Lỗi Server): “Lỗi không phải do bạn, là do server có vấn đề!” (500 Internal Server Error)
Hãy nhớ những mã này, chúng rất hữu ích để debug đấy!
Nãy mình có nói PUT và PATCH, vậy sự khác biệt giữa PUT và PATCH là gì?
PUT: Giống như bạn có một cái CV cũ, bạn vứt nó đi và thay bằng một cái CV mới hoàn toàn.
PATCH: Bạn chỉ sửa lại một dòng nhỏ trong CV mà thôi, ví dụ như số điện thoại.
Hiểu rồi chứ? PUT thay thế hoàn toàn, PATCH chỉ sửa một phần.
Trong API, chúng ta thường nói về CRUD operations. Đây là những thao tác cơ bản với dữ liệu:
Create (Tạo mới): Dùng POST
Read (Đọc/Lấy): Dùng GET
Update (Cập nhật): Dùng PUT hoặc PATCH
Delete (Xóa): Dùng DELETE
Nhớ nhé, CRUD là xương sống của mọi API!
Khi bạn xem danh sách sản phẩm trên Shopee, đôi khi bạn thấy URL kiểu shopee.vn/search?categoryabc&price100k. Ở đây, categoryabc và price100k là Query parameters. Chúng được thêm vào sau dấu “?” để lọc hoặc sắp xếp dữ liệu. Còn Path parameters thì sao? Chúng là một phần của chính URL, ví dụ như shopee.vn/product/12345. 12345 là path parameter, dùng để định danh một tài nguyên cụ thể. Giống như bạn đến quán phở, bạn có thể gọi “phở tái” (path parameter) hoặc “phở tái, thêm quẩy” (query parameter).
Một request được gọi là Idempotent nếu bạn gửi nó nhiều lần mà kết quả vẫn giống như gửi một lần duy nhất. Ví dụ, DELETE /users/1 là idempotent. Bạn xóa User 1 một lần hay 100 lần thì User 1 vẫn chỉ bị xóa một lần duy nhất. POST /users để tạo User mới thì không phải idempotent, vì gửi nhiều lần sẽ tạo ra nhiều User.
HATEOAS (Hypermedia As The Engine Of Application State) là một nguyên tắc “cao cấp” hơn trong REST. Nó có nghĩa là API sẽ cung cấp các liên kết (links) trong phản hồi của nó, hướng dẫn client các hành động tiếp theo có thể thực hiện. Giống như cô bán phở không chỉ đưa bạn tô phở mà còn chỉ cho bạn chỗ lấy đũa, chỗ để chén vậy.
Nếu bạn đã từng dùng một ứng dụng nào đó mà tự nhiên nó ngừng hoạt động vì nhà phát triển thay đổi API, bạn sẽ hiểu tầm quan trọng của Versioning API. Versioning là cách quản lý các phiên bản API khác nhau để đảm bảo các ứng dụng cũ vẫn hoạt động bình thường (backward compatibility). Giống như Facebook không thể ép tất cả người dùng phải update ứng dụng lên phiên bản mới nhất cùng lúc, họ phải duy trì các phiên bản cũ một thời gian.
Content negotiation trong API cho phép client và server “thương lượng” với nhau về định dạng dữ liệu mong muốn (JSON, XML…). Client sẽ gửi các header như Accept: application/json để nói “Tôi muốn dữ liệu dưới dạng JSON!”, và server sẽ cố gắng đáp ứng.
Nhắc lại một lần nữa, Stateless trong REST API nghĩa là server không lưu trữ bất kỳ thông tin nào về trạng thái của client giữa các yêu cầu. Mỗi yêu cầu phải chứa đủ thông tin để server xử lý. Điều này giúp API dễ dàng mở rộng và chịu tải tốt hơn.
OAuth 2.0 là một framework authorization rất phổ biến. Nó cho phép một ứng dụng truy cập tài nguyên của bạn trên một dịch vụ khác (ví dụ: một ứng dụng game truy cập danh sách bạn bè trên Facebook của bạn) mà không cần bạn phải cung cấp mật khẩu trực tiếp cho ứng dụng game đó. An toàn hơn nhiều!
JWT (JSON Web Token) là một “chiếc vé” nhỏ gọn, an toàn, chứa thông tin được mã hóa và ký số. Sau khi bạn đăng nhập, server cấp cho bạn một JWT. Bạn dùng nó để chứng minh danh tính trong các yêu cầu tiếp theo mà không cần gửi lại mật khẩu.
Đã bao giờ bạn vào một trang web, và nó bị lỗi CORS chưa? CORS (Cross-Origin Resource Sharing) là một cơ chế bảo mật của trình duyệt. Nó quy định rằng các trang web chỉ được phép truy cập tài nguyên từ cùng một domain mà thôi, trừ khi server cho phép rõ ràng. Nó giống như một người bảo vệ cổng thành, chỉ cho phép những người có “giấy phép” từ thành khác vào.
Khi bạn có hàng trăm API nhỏ trong một hệ thống lớn (microservices), việc quản lý chúng sẽ rất phức tạp. Đó là lúc API Gateway xuất hiện! Nó là một “cánh cổng” duy nhất mà mọi yêu cầu từ bên ngoài đều phải đi qua. API Gateway sẽ xử lý việc định tuyến yêu cầu, xác thực, giới hạn tốc độ và nhiều thứ khác. Giống như một người quản lý khách sạn, tiếp nhận khách, kiểm tra đặt phòng và chỉ dẫn đến đúng phòng vậy.
HTTPS cực kỳ quan trọng cho API! Nó mã hóa tất cả dữ liệu được truyền giữa client và server, bảo vệ bạn khỏi những kẻ rình mò (“man-in-the-middle attacks”). Giống như bạn gửi thư mật qua một đường hầm an toàn vậy.
Cẩn thận với SQL Injection trong API! Đây là một kỹ thuật tấn công mà kẻ xấu chèn các đoạn mã SQL độc hại vào yêu cầu API, có thể khiến cơ sở dữ liệu của bạn bị xâm phạm. Nguy hiểm lắm đấy!
Để chống lại SQL Injection và các cuộc tấn công khác, chúng ta cần Input validation trong API. Nghĩa là, mọi dữ liệu đầu vào từ client đều phải được kiểm tra và làm sạch kỹ lưỡng trước khi xử lý. Giống như cô bán phở phải rửa rau sạch sẽ trước khi nấu vậy.
API throttling cũng giống như Rate Limiting, nhưng thường là một chính sách được áp dụng để kiểm soát tốc độ yêu cầu, bảo vệ server khỏi bị quá tải hoặc để đảm bảo công bằng giữa các người dùng.
Khi bạn dùng JWT hay OAuth, bạn thường sẽ thấy Bearer token. Đây là một loại access token được gửi trong header Authorization của yêu cầu API. Nó giống như bạn đưa “vé vào cửa” cho người gác cổng vậy.
Thế Refresh token khác access token như thế nào? Access token giống như vé vào cửa trong 1 giờ, nó có thời gian sống ngắn. Còn Refresh token giống như thẻ thành viên trọn đời, bạn dùng nó để lấy một vé vào cửa mới (access token mới) mà không cần phải đăng nhập lại.
Giờ đến một “đối thủ” của REST API: GraphQL! GraphQL cho phép client chỉ định chính xác dữ liệu mà họ cần, không hơn không kém. REST thường trả về một cấu trúc dữ liệu cố định, dù bạn có cần tất cả hay không. GraphQL giống như bạn đến một nhà hàng và tự thiết kế món ăn của mình, còn REST là bạn chỉ có thể chọn món có sẵn trong menu.
Trong GraphQL, Schema là bản thiết kế của API, định nghĩa tất cả các loại dữ liệu, các truy vấn (queries) và các thay đổi (mutations) có thể thực hiện.
Query và Mutation trong GraphQL khác nhau ra sao?
Query: Dùng để đọc dữ liệu. “Cho tôi xem danh sách các cuốn sách của tác giả này.”
Mutation: Dùng để thay đổi dữ liệu (tạo, cập nhật, xóa). “Thêm cuốn sách này vào thư viện.”
Mỗi “trường” (field) trong Schema GraphQL đều có một Resolver. Resolver là một hàm nhỏ, chịu trách nhiệm tìm nạp hoặc tính toán dữ liệu cho trường đó. Giống như mỗi món ăn trong menu có một đầu bếp riêng để chế biến vậy.
Nhờ GraphQL, chúng ta tránh được Over-fetching (nhận thừa dữ liệu) và Under-fetching (cần nhiều request để lấy đủ dữ liệu), vốn là hai vấn đề thường gặp với REST API.
Trong quá trình phát triển, Integration testing cho API rất quan trọng. Nó kiểm tra xem các API và các thành phần khác trong hệ thống có hoạt động tốt với nhau không. Giống như thử xem các bộ phận của một chiếc xe có khớp với nhau không trước khi đưa ra thị trường.
Postman là một công cụ “thần thánh” cho các developer. Nó giúp bạn gửi các request đến API, xem phản hồi, kiểm tra, tạo tài liệu và theo dõi hiệu suất API. Một người bạn không thể thiếu!
Contract testing trong API là một cách để đảm bảo rằng cả nhà cung cấp API (provider) và người tiêu dùng API (consumer) đều tuân thủ cùng một “hợp đồng” về cách API hoạt động.
Để phát triển và thử nghiệm, đôi khi chúng ta dùng Mock API. Đây là một phiên bản giả lập của API thật, giúp bạn phát triển ứng dụng mà không cần chờ API thật hoàn thiện.
Load testing API giúp chúng ta kiểm tra xem API có “đủ sức” để xử lý một lượng lớn yêu cầu cùng lúc hay không. Giống như kiểm tra xem một cây cầu có chịu được trọng tải của hàng trăm xe cùng lúc không vậy.
API documentation – tài liệu hướng dẫn sử dụng API – cực kỳ quan trọng! Nó giống như một cuốn sổ tay hướng dẫn chi tiết, giúp các lập trình viên khác hiểu cách dùng API của bạn. Không có tài liệu, API của bạn dù tốt đến mấy cũng khó được sử dụng.
Để tạo tài liệu API một cách chuyên nghiệp, chúng ta có Swagger/OpenAPI. Đây là một tiêu chuẩn để mô tả RESTful API, sau đó có thể tự động tạo ra tài liệu tương tác.
Webhooks khác API như thế nào? API thường là “kéo” (pull) – bạn gửi yêu cầu và nhận phản hồi. Webhooks thì “đẩy” (push) – server sẽ tự động gửi thông báo cho bạn khi có sự kiện nào đó xảy ra. Giống như bạn gọi điện hỏi nhà hàng “còn món phở không?” (API), còn webhook là nhà hàng tự động gọi cho bạn khi có món phở mới ra lò vậy.
Khi dữ liệu quá lớn, Pagination trong API giúp chia dữ liệu thành nhiều trang nhỏ. Giống như bạn đọc một cuốn sách dày, bạn đọc từng trang một chứ không đọc hết cả cuốn cùng lúc.
Caching trong API hoạt động bằng cách lưu trữ tạm thời các phản hồi của API. Khi có yêu cầu tương tự đến, API sẽ trả về dữ liệu đã lưu trữ mà không cần xử lý lại, giúp tăng tốc độ và giảm tải cho server.
ETag trong HTTP là một “dấu vân tay” cho một phiên bản cụ thể của tài nguyên. Nó giúp API biết liệu tài nguyên ở client có còn mới hay không, tránh việc tải lại dữ liệu không cần thiết.
Circuit breaker pattern trong API là một cơ chế bảo vệ. Nếu một dịch vụ phụ trợ bị lỗi, nó sẽ “ngắt mạch” tạm thời các yêu cầu đến dịch vụ đó để tránh làm sụp đổ toàn bộ hệ thống. Giống như cầu chì điện vậy.
API rate limit thường được set như thế nào? Nó phụ thuộc vào nhiều yếu tố: gói dịch vụ của người dùng, độ nhạy cảm của endpoint, và khả năng của hạ tầng server.
Trong kiến trúc Microservices architecture, mỗi dịch vụ nhỏ có API riêng. Để quản lý và định tuyến các yêu cầu, chúng ta cần đến API Gateway.
Service mesh là một lớp hạ tầng quản lý việc giao tiếp giữa các dịch vụ trong môi trường microservices. Nó xử lý việc định tuyến, tải cân bằng, bảo mật và quan sát.
Có nhiều API versioning strategies phổ biến: thêm version vào URL (URI versioning), vào header (header versioning), hoặc vào query parameter (query parameter versioning).
Deprecation policy cho API là một kế hoạch rõ ràng để thông báo và loại bỏ các phiên bản API cũ một cách có kiểm soát, giúp người dùng có thời gian chuyển đổi.
Batch requests trong API cho phép bạn gom nhiều yêu cầu nhỏ thành một yêu cầu lớn duy nhất. Điều này giúp giảm số lượng kết nối mạng và tăng hiệu quả.
Long polling vs WebSocket? Long polling giữ kết nối mở chờ dữ liệu, còn WebSocket là giao tiếp hai chiều, thời gian thực. WebSocket tốt hơn cho các ứng dụng cần cập nhật liên tục.
API proxy là một trung gian giữa client và server. Nó có thể được dùng để thêm các tính năng như bảo mật, caching, ghi nhật ký mà không cần sửa đổi API gốc.
BFF (Backend for Frontend) pattern là việc tạo ra các API riêng biệt cho từng loại client (web, mobile). Ví dụ, API cho web có thể trả về nhiều dữ liệu hơn API cho mobile.
API composition là việc kết hợp phản hồi từ nhiều API khác nhau thành một phản hồi duy nhất cho client.
Idempotency key là một mã định danh duy nhất được gửi kèm theo yêu cầu, đảm bảo rằng dù yêu cầu có được gửi nhiều lần thì nó cũng chỉ được xử lý một lần duy nhất.
Để đảm bảo API hoạt động tốt, chúng ta cần API monitoring để theo dõi các chỉ số như thời gian phản hồi, tỷ lệ lỗi, thông lượng và tính khả dụng.
Blue-green deployment cho API là một chiến lược triển khai mới bằng cách chạy đồng thời hai phiên bản (cũ và mới). Khi phiên bản mới ổn định, toàn bộ traffic sẽ được chuyển sang đó.
Canary deployment trong API là việc triển khai phiên bản mới cho một nhóm nhỏ người dùng trước khi triển khai rộng rãi. Nếu có vấn đề, chỉ ảnh hưởng đến một phần nhỏ người dùng.
API health check endpoint là một địa chỉ đặc biệt mà bạn có thể truy cập để kiểm tra xem dịch vụ API có đang hoạt động bình thường không.
Khi ghi nhật ký (logging) yêu cầu/phản hồi, chúng ta nên bao gồm: thời gian, ID người dùng, endpoint, mã trạng thái, thời gian phản hồi và thông báo lỗi.
Compression trong API response (ví dụ: dùng gzip) giúp giảm kích thước dữ liệu được truyền, từ đó tăng tốc độ phản hồi và tiết kiệm băng thông.
Hypermedia controls trong API là việc nhúng các liên kết và hành động vào phản hồi của API để hướng dẫn client biết phải làm gì tiếp theo.
Content-Type header cực kỳ quan trọng vì nó chỉ định định dạng dữ liệu được gửi trong yêu cầu hoặc phản hồi. Server và client cần biết để phân tích cú pháp đúng.
API sandbox environment là một môi trường thử nghiệm riêng biệt, nơi các nhà phát triển có thể thử nghiệm API mà không ảnh hưởng đến hệ thống sản xuất thật.
Partial response trong API cho phép client chỉ định chính xác những trường dữ liệu mà họ muốn nhận, giúp giảm kích thước payload.
ETL (Extract, Transform, Load) và API có mối liên hệ chặt chẽ. API thường được dùng để “extract” (trích xuất) dữ liệu từ các hệ thống khác trong các pipeline ETL.
Trong kiến trúc Serverless, API Gateway thường được dùng để kích hoạt các hàm serverless (như AWS Lambda, Google Cloud Functions) dựa trên các yêu cầu HTTP.
gRPC khác REST API như thế nào? gRPC sử dụng Protocol Buffers để định nghĩa cấu trúc dữ liệu và HTTP/2 để giao tiếp. Nó thường nhanh hơn và hiệu quả hơn REST, đặc biệt cho giao tiếp giữa các dịch vụ trong cùng một hệ thống.
API federation là việc kết hợp nhiều API khác nhau thành một giao diện thống nhất cho client.
Schema validation trong API là quá trình kiểm tra xem dữ liệu đầu vào hoặc đầu ra có tuân thủ theo schema đã định nghĩa trước hay không.
API analytics thu thập các thông tin chi tiết về việc sử dụng API, như các endpoint phổ biến, mẫu sử dụng, và các vấn đề về hiệu suất.
Middleware trong API là các hàm được thực thi trước khi yêu cầu đến được bộ xử lý chính của route. Chúng thường được dùng để xác thực, ghi nhật ký, kiểm tra quyền.
Các chiến lược API rate limit phổ biến bao gồm Token bucket, Leaky bucket, Fixed window và Sliding window.
Mutual TLS (mTLS) trong API là một cơ chế bảo mật mạnh mẽ, trong đó cả client và server đều xác thực lẫn nhau bằng cách sử dụng chứng chỉ số.
API payload encryption là việc mã hóa phần thân (body) của yêu cầu/phản hồi API, bổ sung thêm một lớp bảo mật ngoài việc mã hóa lớp vận chuyển (HTTPS).
Các thực tiễn tốt nhất cho Webhook security bao gồm xác minh chữ ký, danh sách IP cho phép, chỉ sử dụng HTTPS và đảm bảo tính idempotent.
API deprecation header là một HTTP header đặc biệt thông báo rằng một endpoint sắp bị loại bỏ và thời gian còn lại.
Consumer-driven contracts là một phương pháp mà các “người tiêu dùng” API định nghĩa những gì họ mong đợi từ API, và “nhà cun
API, REST API, HTTP methods, JSON, GraphQL, Webhooks, Authentication, Authorization, API Key, Rate limiting, Endpoint, Giải mã công nghệ
