Những điều mà REST chưa làm được?



  • Bài viết được dịch từ Dive Into GraphQL
    Đây là bài đầu tiên của series Dive Into GraphQL Series. Nhưng rất hay là bài viết này lại không nói về GraphQL là gì mà nói về những vấn để nó giải quyết. Và chúng ta sẽ tìm hiểu về những gì REST chưa làm được.

    REST và kiến trúc cho API

    Đầu tiên, không có gì là sai với REST cả, REST là hướng giải quyết hoàn hảo cho cho vấn đề xây dựng một kiến trúc API. Trước khi có REST, SOAP một web service yêu cầu các công cụ rất phức tạp, mất nhiều thời gian để cấu hình và rất nhiều việc phải làm bằng tay. Việc tạo ra web service đòi hỏi các SDK bản quyền, hoặc mã nguồn không publish. Thời điểm đó, việc tạo ra một web service từ trình duyệt là điều không tưởng.

    REST, được phát minh từ năm 2000 và trở lên phổ biến 2007, bởi cú pháp đơn giản của nó. REST làm cho request và response trở lên dễ dàng build và parse, đó là lí do tại sao các lập trình viên frontend và backend lại dễ dàng yêu thích nó đến vậy. REST cũng stateless và cacheable, nó làm phát triển cộng đồng sử dụng web service. Nó hoạt động tốt cho đến hiện nay, kiến trúc API ở mọi nơi và REST đang là một sự lựa chọn tốt.

    Nhưng thế giới đã thay đổi từ năm 2007. Hãy xem tại sao.

    Internet hiện nay chủ yếu là di động

    Năm 2015, Google đã thông báo điều đầu tiên, chúng tôi nhận được nhiều lượt tìm kiếm từ di động hơn từ máy tính. Từ đó, các nhà cung cấp Internet đã phát triển băng tần cho Internet di động, kết nối các cable cùng với nhau. Vì vậy cần phải đối mặt: những sản phẩm web apps được xây dựng ngày nay sẽ chủ yếu được sử dụng bởi các thiết bị di động, chứ không phải wifi.

    Thiết bị di động 4G hay 3G đều chậm hơn wifi, bởi vì môi trường truyền sóng radio dao động giữa 100ms và 600ms trên 4G(3500ms trên 3G), và cũng bởi vì số lượng kết nối di động rất nhiều, nó ảnh hưởng đến tốc độ và độ trễ.

    Với mỗi HTTP request, thời gian reponse trả về là 1 giây, nó được nghiên cứu user's flow of thoughts limit bởi chuyên gia UX Jakob Nielsen. Điều đó có nghĩa là tối đa số HTTP request của ứng dụng di động có thể thực hiện mà không mất dữ liệu chỉ là 1.

    Đấy là chưa kể đến thời lượng pin. Sử dụng sóng radio rất tốn năng lượng, vì vậy thiết bị di động sẽ tắt radio ngay khi có thể, dẫn tới việc mất các kênh kết nối với trạm phát sóng. Để thực hiện request thiết bị di dộng cần phải kết nối đến trạm phát sóng để gửi HTTP request. Vì vậy, vấn đề thời lượng pin cũng ảnh hưởng đến người thiết kế App.

    Kiến trúc hướng dịch vụ (cho client)

    Tưởng tượng ưng dụng Twitter-like sử dụng REST API cho backend. Hãy lên danh sách những dữ liệu mà cần phát fetch để hiển thị lên trang chính:

    REST backend sẽ cần 1 endpoint(địa chỉ url)/1 dữ liệu. Vì vậy ứng dụng sẽ phải gửi request đến ít nhất những endpoint:

    1. GET /user current user name và avatar
    2. GET /notifications số các thông báo chưa đọc
    3. GET /tweets danh sách 20 các bài viết mới nhất
    4. GET /users?ids=[123, 456, 789, ...] thông tin profile của tác giả của 20 bài viết mới nhất
    5. GET /tweet_stats?ids=[123, 456, 789, ...] stats của 20 bài viết mới nhất
    6. POST /views gửi view stats cho những tweets đã được hiển thị

    Đó là 6 HTTP request - chưa tính các request cho avatar images, hay các media nhúng trong tweet. Resquest 4, 5 sẽ phải chờ request 3. Và với 1 trang đơn giản cần hơn 1 giây để lấy các data cần thiết.

    Bên cạnh đó, web và ứng dụng di động sử dụng nhiều hơn 1 nhà cung cấp service(được hiểu là nhiều hơn 1 HTTP domain). Ví dụ như: authentication, avatars, comments, analytics, ... Vấn đề độ trễ trở lên rất vất vả, bởi mỗi domain mới lại cần đến phân tích tìm kiếm DNS và HTTP client không thể giữ kết nối giữa các domain.

    Tóm lại, nhược điểm chính của REST là làm cho clients trở lên chậm hơn, đặc biệt trên di động.

    Nhóm các request

    Một trong những giải pháp là data inclusion. Ý tưởng là request nhiều dữ liệu từ 1 endpoint, server sẽ dữ liệu liên quan:

    GET /tweets?include=authors,stats
    

    Nó cho phép gộp request 3, 4, 5 request. Data inclusion không cho phép gộp các request mà không liên quan đến nhau (ví dụ như tweets và notifications)

    Năm 2013, Facebook giới thiệu một giải pháp khác. Nó gọi là the Batch endpoin. Nó là 1 REST endpoint, bạn có thể gửi nhiều sub-request trong batch query parameter:

    curl \
        -F 'access_token=...' \
        -F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/friends?limit=50"}]' \
        https://graph.facebook.com
    

    Một cách khác, Facebook server queries cho những data stores, và nhóm các kết quả vào 1 JSON response:

    [
        { "code": 200,
          "headers":[
              { "name": "Content-Type",
                "value": "text/javascript; charset=UTF-8" }
          ],
          
          
          "body": "{\"id\":\"…\"}"},
        { "code": 200,
          "headers":[
              { "name":"Content-Type",
                "value":"text/javascript; charset=UTF-8"}
          ],
          "body":"{\"data\": [{…}]}}
    ]
    

    Không có chuẩn có nghĩa là có quá nhiều chuẩn

    REST không phải là một chuẩn, nó là một kiểu kiến trúc, một bộ các quy tắc.

    Lập trình Frontent và Backend cần một cam kết

    Hướng giải quyết

    Nguồn: Viblo



Có vẻ như bạn đã mất kết nối tới LaptrinhX, vui lòng đợi một lúc để chúng tôi thử kết nối lại.