Sử dụng Fiddler Test Rest API và Nghe- Bắt Gói Tin

Sử dụng Fiddler Test Rest API và Nghe- Bắt Gói Tin

tháng 7 16, 2017
    Hi mọi người. Ở một bài viết gần nhât mình có giới thiệu về một số công cụ và extension mà các dev hay sử dụng. Do giới hạn về độ dài và bài viết lên mình chỉ xin phép dừng ở mức giới thiệu sơ lược qua để mọi người cùng biết thôi. Ở bài viết này mình sẽ đi chi tiết vào một công cụ được lập trình viên rất ưa thích để test và nghe các gói tin. Nói đến đây thì bạn nghĩ ra ngay nó là gì rồi đó. Vâng nó là Fiddler. Nóng hổi hấp dẫn quá nhể 😎. Vạy thì Mình sẽ giới thiệu các feature của nó ngay sau đây. (Đa số toàn hình ảnh lên bài viết nó dài các bạn đừng nhìn dài quá mà bỏ nhé, bỏ xong là thấy là phi phạm cả cuộc đời đây nhé 😆). Ok nội dung bài viết của mình sẽ đi qua các danh mục chính như dưới đây:
  1. Giới thiệu về Fiddler
  2. Test Restfull Api với Fiddler
  3. Test Gói tin với Fiddler

1. Giới thiệu về Fiddler

    Fiddler là một tiện ích test resfull api và nghe, bắt các gói tin miễn phí được phát hành bởi hãng Telerik. Không giống như Wireshark, Fiddler chỉ bắt nghe các gói tin truyền tải giữa máy tính của bạn và internet (Wireshark thì bắt cả các giao thức trong mạng Lan ...). Việc tập chung chỉ nghe các gói tin truyền tải với internet giúp Fiddler gọn, nhẹ và đủ dùng không dưa thừa như Wireshark và được các lập trình viên ưa dùng hơn. Với fiddler bạn có thể làm những gì:
  • Test restfull api web service: bạn sẽ không cần phải chạy web lên và test từng function cho api nữa. Với fiddler bạn có thể test api giả lập ngay trước khi xây dựng một giao diện web có call api. Fiddler hỗ trợ hầu hết các method resfull như get, post, delete, put, patch ... cộng thêm một vài giao thức lạ hoắc mà mình cũng chẳng biết làm cái gì luôn 😅.
  • Test gửi, nhận các gói tin: phần này mình thấy nó hay này. Đại loại với tính năng này bạn có thể nghe các gói tin từ các nguồn dữ liệu trang web khác => phân tích api và lấy được một số api nếu họ public. Hoặc trong quá trình test một sản phẩm website mà bạn đang xây dựng bạn thử một tính năng có call tới api và thấy nó lăn đùng ra chêt, hoặc là kết quả không được như mong muốn, ooh vậy thì bật Fiddler lên xem sao, bạn chỉ cần chạy lại chức năng và vào cửa sổ của fiddler xem api đó được request lên server, mở ra phân tích các thông tin body, params mà bạn đã request lên server... quá tuyệt vời rồi nhỉ. Nhưng mà chưa hết đâu, để bên dưới mình giới thiệu thêm tiếp nhé.
    Oke cha này nói nhiều quá 😅. Giờ tôi muốn sử dụng thì làm sao. Thì cài đặt ngay Fiddler tại đây chứ còn sao 😁. Oke cài đặt xong suôi rồi giờ thử bật lên và dạo qua xem Fiddler có cái gì hay mà cu cậu này cứ khen hoài vậy ta. Thấy rồi nhé, giao diện đơn giản ghê:
    Thoạt nhìn qua thì Fiddler có 3 phần chính là menu và 2 cửa số làm việc chính nằm bên trái và bên phải. Chi tiết nó như này:

  • Menu: cung cấp một số tiện ích để làm việc nhanh hơn như: gửi lại request ngay, delete request, lưu trữ lại các request, decode request ...vv
  • Cửa sổ hiển thị các gói tin gửi và nhận giữa client và server (nằm bên trái): tại đây bạn có thể thực hiện một số tác vụ như
    • view và decode các request: để xem một số thông tin cơ bản. Bạn cứ thử truy cập bất kỳ trang web nào trên internet thử coi và quay lại cửa số lại, lúc này thì nó ko còn trắng xóa đâu mà nhiều be bét các thứ linh tinh luôn :D .
    • select và save một hoặc nhiều request để dành cho việc sau này dùng lại hoặc gửi qua lại cho đứa khác test và sử dụng
  • Cửa sổ hiển thị các công cụ làm việc (nằm bên phải): tại đây có rất nhiều tab làm việc tuy nhiên mình sẽ chỉ liệt kê một số tab thường sử dụng và cần thiết như dưới đây
    • Inspectors: tab này là tab phân tích các thông tin gửi và nhận. Bạn có thể xem các body data được gửi lên, xem các resonpse dưới dạng json hay xml được gửi về, xem các header có đính kém ở các gói tin, xem cookie đính kèm, mã cache ... và rất nhiều cái khác đang chờ bạn khám phá thêm nhé.
    • Composer: tab này dùng để giả lâp test restfull api, thèng này giả lập tuy không bằng post man được nhưng sử dụng thì cũng tạm. Có khá nhiều giả lập cho các method restfull như get, post, delete. Bạn cũng có thể giả lập thêm các header request lên nữa
    • Timeline: tab này giúp theo gõi thời gian gửi và nhận một gói tin mà bạn lựa chọn bên cửa sổ result
    Rồi giờ thì bắt tay vào việc test thử các request response luôn xem sao nhé.
    Ak khoan, fiddler mặc định sẽ không nghe các gói tin request từ https đâu. Vậy thì ta phải vào bật ngay ngay chế độ này trước khi test lên thôi. Tại cửa sổ giao diện fiddler bạn chọn cho mình cấu hình theo chỉ dẫn: Tool > Telerik Fiddler Option > Chọn Tab Https > Tích chọn Capture HTTPS CONNECTs và Decrypt HTTPS traffic.
             
Hình ảnh: Thiết lập lắng nghe giao thức https.
    Giờ thì để chuẩn bị cho việc test mình có create 1 resfull api cơ bản bằng nodejs và mongodb với mongoLab và host nó trên heroku theo địa chỉ này: https://fiddler-api.herokuapp.com/ .Nó chỉ cơ bản gồm các api thêm, sửa, xóa và delete trong model có tên User. Bạn đừng lo lắng quá vì dưới đây mình sẽ demo các api của nó thông qua fiddler nhé.

2. Test Restfull Api với Fiddler

- Hiện tại mình có thể 4 api chính làm việc trong sample này là: get, post, put, delete tương ứng với lấy danh sách các user, tạo 1 user, cập nhật thông tin user và xóa 1 user. Trước tiên mình sẽ test với method GET
    Thử test với api get xem sao: Bạn làm theo từng bước như này nhé: B1: Chọn 1 result bất kỳ trong cửa số result => B2: Chọn Tab Composer => B3: Tab Parsed => B4: Chọn method sử dụng là GET => B5: Nhập url của bạn cần test vào; ở đây mình nhập URL: https://fiddler-api.herokuapp.com/user => B6: Nhấn chọn execute. Bạn có thể coi qua hình bên dưới nhé

Hình ảnh: Test get method
    Oke xong rồi giờ bạn chuyển qua tab Inspectors => Nhìn xuống bên dưới chọn tab JSON => Xem kết quả hiện thị api và mình vừa call này. Bên trái success 200 rùi, bên phải JSON data cũng có luôn => Xem như bước đầu test thành công
            
    Hình ảnh: Hiển thị kết quả sau khi thực thi method get
    Giờ mình thử test thêm api post gửi nhận body data ra sao nhé. Mình sẽ call thử api sample: https://fiddler-api.herokuapp.com/user với method POST <=> create user. Bạn tiếp tục quay lại Tab Composer và thực hiện tương tự các bước từ 1 tới 5 như method GET, có điều giờ bạn cần lựa chọn method là POST=> chuyển sang B6: Thiết lập cho header request Content-type là application/json => B7: Nhập vào chuỗi json data, chuỗi này chính là body gửi lên server nè. => B8: Nhấn Execute để test thử. (Xem thêm minh họa phần dưới)

Hình ảnh: Test post method
    Bạn chuyển lại tab Inspectors để xem kết quả của method POST. Vậy là oke thành công rồi, mình đã test thành công api và đã tạo được 1 user thành công rồi nhé. Bạn có thể xem thêm hình dưới

Hình ảnh: Hiển thị kết quả sau khi thực thi post request
    Các method delete, path, put cũng tương tự các bạn có thể tự test thử xem sao nhé. Cũng không khó cho lắm nhỉ 😃.
    Giờ mình giờ thử đi vooc vạch thêm chút cái tab Inspector coi sao nhỉ,,, Thèng inspectors này bên trong cũng nhiều thằng con ghê này.

Hình ảnh: Cửa sổ làm việc Inspectors
    Cái hình này xấu quá các bạn thông cảm nhé. Thoạt nhìn qua thì tại tab Inspectors có 2 cửa số trên và dưới riêng biệt. Nhìn kỹ lại mới thấy là cửa số trên đại diện cho các thông tin yêu cầu gửi đi, Cửa số dưới đại diện cho các thông tin response nhận về. Mình sẽ đi chi tiết vào 2 cửa sổ này để xem các tab của nó có gì nhé
  • Phần gửi thông tin yêu cầu từ client (vị trí phía trên) bao gồm các tab con:.
    • Headers: Chỗ này có một vài thông tin header mà mình có định nghĩa gửi lên, ở method post ở trên mình có define 1 header là Content-Type: application/json, lên giờ nó sẽ hiển thị bên trong này, đương nhiên là khi bạn gửi sẽ có 1 số header mặc định khác mà bạn không biết. Giờ thì bạn có thể biết rồi đấy, bằng cách sử dụng fiddler là biết ngay 😁.
    • TextView/ SyntaxView/ HexView: Bật 3 tab này lên thấy nó giống giống nhau, nó đều hiện thị body data mà mình gửi lên, có điều cách hiển thị của nó hơi khác nhau một chút thôi.
    • WebForms: Phần này có phần là
      • QueryString; Tức là các dữ liệu gửi theo kiểu dạng params trên đường link chẳng hạn, ví dụ như minh call api:  https://fiddler-api.herokuapp.com/user?page=1... thì => params hiển thị trong này sẽ là Name: page, Value = 1
      • Content-Type is 'application/json' .. : Phần này hiển thị các data body được gưi đi. Tuy nhiên khi bạn gửi dưới dạng application/json thì nó không hiển thị đâu vì hiện tại thằng bên dưới này chỉ hỗ trợ hiển thị các body khi gửi lên với content-type bằng 'x-www-form-urlencoded'
    • Auth: hiển thị các header authenticate mà bạn có đính kèm... có thể kể đến như header huyền thoại Authorization  để xác thực Bearer token mà các dev mobile hay backend làm việc suốt ngày này.
    • Raw: Hiển thị tổng quan header, body data gửi lên
    • json/ xml: Đều là cách hiển thị các thông tin body gửi lên theo đúng ý nghĩa của từ khóa 
  • Phần nhận các phản hồi từ server trả về (vị trí phía dướii): về cơ bản các tab con của nó và ý nghĩa giống như phần gửi thông tin yêu cầu mà mình đã phân tích ở trên. Nó có cung cấp thêm 1 số tab tùy chọn xem trước như Image View và HexView, và Caching. Tuy nhiên bạn không cần quan tâm mấy tab này nhiều vì nó rất ít sử dụng
      Giờ thì test Resfull api với xem các thông tin inspector cũng được kha khá rồi. Mình tiếp tục chuyển qua phần 3 để xem Fidder có thêm cái gì hay nữa nhé

3. Test Gói tin với Fiddler

Tại phần mục này mình sẽ test thử các tính năng nghe, edit, giả lập, lưu trữ các gói tin ...
    Nghe gói tin: Bạn thử tự test coi sao nhé... Cái này thì bạn chỉ cần lên đại một trang web và truy cập là thấy trong cửa số result xuất hiện ngay cả đống gói tin. Tuy nhiên chúng ta lên sử dụng phương pháp này khi phát triển với website động sử dụng call ajax hay fetch api. Khi bạn sử dụng các ứng dụng SPA ở client viết bằng các ngôn ngữ như Angular, React hay Vue... thì vô tình một body data nào đó gửi lên lại gây ra một lỗi thất bại. Giờ thi bạn chả biết ra sao, không biết là do mình gửi lên body data sai hay là do mấy lão backend viết sai. Dùng thử cái này coi phát thấy ngay mấy cái api hiện ra lù lù, Thực hiện Inspectors như mình hướng dẫn trên và sẽ biết ngay body data mà bạn gửi lên nó như thế nào => Một số trường hợp cái này cũng khá hữu ích đó :D .
    Edit gói tin: cái này cũng tương đương với decode các gói tin. Ý nghĩa của việc này là bạn muốn edit các gói tin đã request rồi và thay đổi lại các params hay body data để thử giả lập và gửi lại các thông tin bạn vừa thay đổi đó lên server coi sao. 

    Thử example phát coi zô: mình vẫn sẽ thực hiện trên api post ở trên mà mình sử dụng. Sau khi bấm nút thực thi và create user thành công bạn để ý phía bên trái cửa số làm việc của Fiddler có phần Result 200 và Protocols .... Tại đây bạn chuột phải vào mục request hay response mà bạn quan tâm, nó sẽ hiển thị ra một số tình năng có thể kể đến như:
  • Relay > Reissue Requests để gửi lại request đó
  • Unlock for Editing: Cái này thú vị này, bạn có thể chọn tích thao tác này để thay đổi các thông tin api mà bạn request mà bạn vừa gửi lên hoặc các request từ một tác vụ call api nào đó. Khi chọn chế độ này bạn có thể đi trực tiếp và Inspectors và thay đổi các thông tin body data hay params data. Thay đổi mọi key, value mà bạn muốn..  => Thực thi xong ta chỉ việc Chuột phải và chọn replay như bên trên để gửi request mà bạn vừa unlock thay đổi thông tin (Có thể coi đây là giả lập 1 request từ client lên server)
Hình ảnh: replay và unlock
  • Save: Lưu trữ các gói tin: 1 tính năng nữa cũng rất hay và không thể không kể đến là lưu trữ các gói tin request, response về. bạn có thể lưu trữ một hoặc nhiều các request và gửi nó cho các đồng nghiệp bạn bè của mình, giúp họ có thể test api nhanh chóng hơn, các đồng nghiệp cũng có thể thực hiện các thao tác giả lập như mình hướng dẫn. Miễn sao họ cũng đang sử dụng Fiddler vậy là được. Để lưu trữ các api thi bạn làm như hình mà mình mô tả dưới đây nhé:
Hình ảnh: Save và unlock
  • Nhìn vào hình trên bạn có thể thấy mình có rất nhiều api và các request, response lưu trữ. Fiddler cũng cung cấp cho ta các kiểu lưu trữ khác nhau như file zip và file text. Bạn chọn kiểu lưu trữ nào cũng được. Ngoài ra họ cũng cung cấp thêm một số tùy chọn hữu ích khác như:
    • Selected Sessions: chỉ lưu trữ các phiên làm việc được lựa chọn, giống như 4 cái mà mình select trên hình đó (có màu nền xanh da trời đậm <=> được chọn)
    • Request: lưu trữ toàn bộ các phiên làm việc dưới dạng request, (cái này dù có chọn thì nó vẫn lưu hết các request mà không quan tâm)
    • Response: lưu trữ toàn bộ các phiên làm việc dưới dạng phản hồi (cái này cũng giống như request, ko phân biệt chọn hay không chọn cứ là response thì lưu hết)
  • Mark: đánh dấu, tô màu cho các phần request, response tại cửa sổ result mà bạn chọn: Sử dụng cái này trong trường hợp có quá nhiều api hay request, response được gửi, nhận mà bạn muốn đánh dấu để có được một danh sách các request dễ nhìn, dễ tìm kiếm. tính năng này sẽ giúp bạn việc đó.
    Ngoài ra trên thanh menu cũng cung cấp cho bạn khá nhiều tùy chọn như tìm kiếm các host, domain request, hay clear cache, Xóa các request, response config... Tất cả vẫn đang cần bạn khám phá thêm. Tuy nhiên cừng này trong bài viết này cũng là đủ để bạn sử dụng rồi. Hi vọng là bài viết hữu ích cho các bạn muốn sử dụng Fiddler để test gói tin và rest api. Tuy về Rest Api thì nó còn thua kém so với post man nhưng khả năng sử dụng lắng nghe gói tin của nó là khá tuyệt vời và cũng khá hữu ích. Mình cũng xin phép dừng bài viết tại đây, dài quá mọi người lại ném đá tơi bời giờ 😂. Các bạn chia sẻ thêm kinh nghiệm hay nhưng thủ thuật đã từng làm với tool này để mọi người cùng học hỏi thêm nhé!

Thông Tin

Chỉ đơn giản là chia sẻ chút kiến thức ít ỏi. Mình biết khi mình viết blog này cũng là lúc mình nhìn nhận lại kiên thức học tập và làm việc của mình và mình được mọi người góp ý sửa sai cho mình!!

Đăng ký: Đăng Nhận xét (Atom)