REST là gì đã nè :v
REST request sẽ gồm các phần chính: endpoint, HTTP method, Header, Body
Endpoint thì chứa URI của resource
HTTP method thì là type của request gửi lên server gồm: GET, POST, PUT, PATCH, DELETE
Header cung cấp thông tin cho client và server để làm việc với mấy thứ như caching, AB Testing, authentication,…
Body thì là thông tin client muốn gửi tới server – payload của request.
Vậy tại sao chúng ta lại có cái bài viết này? REST có những điểm nào không tốt?
Chả có cái REST API nào nó giống cái nào cả 🙂
Mỗi thằng dev sẽ có một cách nhìn nhận, một cách cấu trúc khác nhau. Nên khi join team hoặc làm việc với 1 cái REST API mới, thì anh em phải đi đọc docs của nó, vì nếu không đọc docs thì thua luôn, vì cái REST API mới có khi nó khác hoàn toàn cấu trúc với cái anh em đã từng biết.
Backend dev khi viết RESTAPI thì đồng thời cũng phải maintain cái docs cho nó luôn, nếu không thì cái thằng ở ý trên á, nó lú chết mẹ.
Khi mà project nó to ra, feature nhiều, thì đồng thời endpoint cũng nhiều thêm.
Mà khi nhiều endpoint thì chuyện gì xảy ra? Overfetching (OF) và Underfetching (UF)
OF là khi fetch data nhiều hơn mình cần :v kiểu khi muốn lấy 1 phần của cái object thôi, thì 1 là lấy nguyên object, 2 là tạo 1 endpoint mới, đúng không?
Rồi khi 1 cái endpoint nó không cung cấp đủ data thì sao? 1 là gọi vài cái endpoint để lấy -> giảm performance, sử dụng nhiều network. 2 là viết 1 endpoint mới để handle tất cả đống đó (ái endpoint này hầu như sẽ chỉ được sử dụng ở 1 nơi, và thời gian response của nó cũng khá lâu)
REST không có type (không typed save)
Tất nhiên 🙂 đọc docs thì biết type, nhưng docs nó cũng có thể bị outdated, tất nhiên vẫn có cách giải quyết khác ví dụ như auto generate docs. Nhưng mà cơ bản là, đối với REST, data request hoặc response thì mình dùng nó như kiểu người mù zị á, vì biết type nó là gì đâu.
Vậy thì thằng GraphQL nó có điểm gì mạnh, mà giờ nhiều project dùng?
GraphQL có thể chỉ dùng 1 endpoint
query {
users {
id
name
}
}Ví dụ cái request trên, nó sẽ query users, và chỉ lấy id và name thôi. Loại bỏ OF. Rồi ví dụ muốn lấy thêm gì chỉ việc add vào cái object là được.
Schema
Schema nó giống như cái contract giữa client và server á, nó cũng có thể coi là 1 cái docs. Nếu mọi người biết về grpc, thì nó cũng có 1 cái tựa tựa là proto -> contract giữa client/server. Tương tự, không giống đâu nha.
Typing
Giống như việc viết type Entity zị á, thì GraphQL cũng như v, có type, có relationship…
Đống type này là những cái mà chúng ta muốn sử dụng trong GraphQL.
Query
Cái này dùng để fetch từ GraphQL cho entrypoint.
type Query {
user(id: String!): User!
users: [User]!
}Syntax thì ông nào ưa thì tự đọc nghe 🙂
Mutation
Cái này là kiểu create, update, delete. Khai báo theo kiểu interface (signature của function)
Resolver
Cái này là để handle Query và Mutation
Giống như kiểu đống Query và Mutation là controller zị á, còn resolver này là service của anh em.
Kết
Rồi đó, đây là những cái điểm yếu của REST và GraphQL nó đưa ra solution. Tất nhiên REST vẫn có điểm mạnh hơn GraphQL ví dụ:
– REST có API versions, GraphQL thì ko
– REST response ra đc XML, JSON, YAML, còn GraphQL thì chỉ có JSON
– REST có hệ thống caching auto xịn hơn.
Sign up