How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)

--- Bài mới hơn ---

  • Cách Tạo Api Với Rails (Phần 2) Viết Test Case
  • Học Kiểm Thử Api Trong 10 Phút
  • Giới Thiệu Tool Swagger Ui
  • Cách Viết Rails Api Document
  • Tôi Đã Viết Api Document Cho Dự Án Như Thế Nào?
  • Đầu tiên, chúng ta cùng tìm hiểu:

    A. Testcase là gì?

      Testcase là các trường hợp kiểm thử bao gồm các hành động được thực hiện nhằm kiểm tra từng chức năng của ứng dụng phần mềm có hoạt động đúng theo như mong muốn hay không.

    B. Làm thế nào để có thể viết được Testcase tốt?

    I. Trước khi bắt tay vào việc viết Testcase thì chúng ta cần nhớ những điểm sau đây:

    • Là 1 newbie, mới gia nhập công ty, chúng ta nên hỏi QA leader về template viết Testcase và xin file đó để làm. ( Vì mỗi công ty sẽ có cách viết khác nhau)
    • Viết Testcase nhớ phải bám sát tài liệu yêu cầu ( spec)
    • 1 Testcase ID không quá 15 bước ( step)
    • Trước khi viết Testcase thì ta nên đọc và phân tích tài liệu thật kĩ càng, có chỗ nào chưa hiểu thì đặt Q&A ( Question & Answer) với các member trong team hoặc QA leader hoặc khách hàng để việc viết testcase và test được chính xác và chắc chắn hơn.

    II. Những nguyên tắc để viết TestCase tốt:1. Các trường hợp kiểm thử cần phải đơn giản và minh bạch: (Test Cases need to be simple and transparent)

    • Tạo các testcase đơn giản nhất có thể nhưng vẫn phải rõ ràng và dễ hiểu.

    2. Tạo Testcase với vai trò mình là End -user (người dùng ứng dụng đó)

      Mục tiêu cuối cùng của bất kì dự án phần mềm nào cũng là đáp ứng được tất cả các yêu cầu của khách hàng. Vậy nên đặt vị trí của mình là người dùng thì sẽ thực hiện test được hiệu quả hơn. Chứ không nên có suy nghĩ mình chỉ là QA, chỉ là tester nên mình cứ test theo những gì spec nói thôi. Khi thấy UI nó khó dùng thì ta nên ta feedback lại với PM hay với mọi người để tất cả cùng cân nhắc có nên thay đổi hay không.

    3. Mỗi testcase đều phải được xác định

      Đặt tên ID cho từng testcase để dễ dàng theo dõi

    b, Phân vùng tương đương (Equivalence Partition): Kỹ thuật này phân vùng phạm vi thành các phần / nhóm bằng nhau có xu hướng có cùng hành vi.

    c,Kỹ thuật Bảng quyết định (Decision tables) : Phương pháp này tìm được những tác động khi kết hợp các yếu tốt đầu vào khác nhau và các trạng thái phần mềm mà phải thực hiện đúng các quy tắc nghiệp vụ khác.

    d, Kỹ thuật đoán lỗi (Error Guessing Technique): Đây là đoán / dự đoán lỗi có thể phát sinh trong khi thực hiện test manual.

    5. Review chéo (Peer Review): Sau khi tạo xong Testcase, hãy nhờ đồng nghiệp của bạn review giúp, có thể là QA leader hay QA cùng team để phát hiện ra các case mà bạn còn thiếu hoặc bạn chưa nghĩ tới.

    C. Thực hành viết Testcase:

      Khi join vào dự án, chúng ta được QA Leader giao cho nhiệm vụ là viết Testcase cho màn Login của 1 website với UI như thế này:

    Ta sẽ viết theo format chuẩn như sau:

    Testcase ID Test Scenario Test Steps Test Data Expected Results Actual Results Status

    LG01

    Check UI

    As expected

    Pass

    LG02

    Check button Sign in when user input valid data

    4. User can login successfully and system go to the Homepage

    As expected

    Pass

    LG03

    Check button Sign in when user input invalid data

    4. User cannot login and system shows error message: Email is invalid.

    As expected

    Pass

    Qua 3 ví dụ trên các bạn có thể dễ dàng hơn với việc với Testcase rồi đúng không nào? Tương tự các case trên, các bạn áp dụng Kĩ thuật Bảng quyết định, ta sẽ có thêm các case sau:

    --- Bài cũ hơn ---

  • Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu
  • Cách Test Api Như Thế Nào?
  • Hướng Dẫn Tạo Secure Rest Api Trong
  • Sử Dụng WordPress Rest Api Toàn Tập
  • Cách Sử Dụng Api WordPress Rest
  • Cách Viết Rails Api Document

    --- Bài mới hơn ---

  • Tôi Đã Viết Api Document Cho Dự Án Như Thế Nào?
  • Viết Api Document Cho Dự Án Sử Dụng Laravel
  • Tạo Ứng Dụng Android Đơn Giản Đưa Lên Google Play Trong 10 Tiếng
  • Cách Tạo Ứng Dụng Android / Ios Không Cần Biết Lập Trình
  • Appendix: Cách Tiếp Cận Trung Tâm
  • Như các bạn đã biết, 1 ứng dụng API sẽ không có giao diện cho người dùng trên trình duyệt, thay vào đó sẽ là các dữ liệu kiểu JSON hoặc XML … được hiển thị mà thôi. Do đó, khi viết 1 ứng dụng API đòi hỏi người viết phải viết Documents (Tài liệu) kèm theo để hỗ trợ cho những Developers sử dụng chúng và đặc biệt là QA, những người sẽ gặp nhiều khó khăn hơn trong việc hiểu được tác dụng của các API.

    Có nhiều cách để viết Documents, đơn giản nhất sẽ là viết bằng tay ra file Excel hoặc Word chẳng hạn. Chỉ rõ API này mục đích làm gì, URL để truy cập đến như thế nào, dữ liệu gửi Request là gì, Dữ liệu Response trả về là gì … Xong rồi thì gửi chúng cho bên Developers/QA có như cầu sử dụng để họ đọc. Cách này khá thủ công và tốn nhiều efforts trong khi giá trị mang lại cho những người sử dụng chúng lại chưa chắc đã cao, vì đơn giản chúng không có 1 Format thống nhất và rất dễ thiếu thông tin.

    Hôm nay mình sẽ giới thiệu cho các bạn 1 Tool khá nổi tiếng trong việc viết API docs, đó là Swagger (UI). Cụ thể Swagger là gì thì các bạn có thể search để tìm hiểu, Swagger nên ở phạm vi bài viết này mình xin phép không giới thiệu lại, thay vào đó sẽ mình sẽ đi sâu vào cách triển khai Swagger theo cách “Khoa học” và “Developer” nhất có thể.

    Quay lại 1 chút thì các bài viết trước đây khi hướng dẫn triển khai Swagger UI thường tiếp cận theo hướng copy UI của Swagger rồi “ném” vào Project của mình (clone lại Repository Swagger hoặc copy file CSS, JavaScript của Swagger) không thì viết sẵn 1 file XML (JSON) rồi render lại chúng ra View.

    Còn cách mà “Khoa học” và theo hướng “Developers” ở đây mình muốn nói đến là:

    • Có khả năng tái sử dụng code, viết Docs cũng như viết Code, cái gì giống nhau là gọi lại dùng được
    • Dễ dàng mở rộng (Scale), ví dụ: khi thêm 1 trường vào Model hay đổi tên 1 trường chẳng hạn thì file Documents cũng tự động được update chẳng hạn
    • Tổ chức Trees (Cây thư mục) rõ ràng và khoa học

    Trong Rails thì có 2 Gem thường được dùng để Implement Swagger là: swagger-docs và swagger-blocks. Sự khác biệt lớn nhất giữa 2 Gem này là swagger-blocks được support đến v2.0 của Swagger Specification còn swagger-docs chỉ dừng lại ở v1.2, và theo thông tin trên Repo của swagger-docs thì họ chưa có kế hoạch update lên v2.0. Do đó trong Demo này mình sẽ triển khai với gem swagger-blocks.

    Note: cả 2 gem kể trên đều không sinh ra giao diện UI/UX theo kiểu Swagger mà chỉ sinh ra 1 file .json phù hợp với format của Swagger UI mà thôi, do đó để có giao diện như Swagger mang lại, chúng ta cần 1 Gem nữa là swaggeruiengine.

    Bắt đầu, tạo 1 ứng dụng Rails API bằng cách gõ các lệnh sau trên Terminal:

    Sau đó add thêm 2 Gem mình giới thiệu phía trên vào Gemfile rồi bundle chúng:

    Note: khi triển khai thực tế mình gặp phải 1 vấn đề khi call API bằng tool Postman – tool hỗ trợ test các Request API – thì Oki nhưng khi Deploy lên Server và call API qua lại giữa các Server thì bị trả về 404, sau 1 hồi search thì tìm hiểu ra là do thiếu config CORS. Để khắc phục thì bạn chỉ cần add thêm vào Gem như sau:

    và config cho Rails như sau:

    Trên Repo của gem Swagger-Blocks có giới thiệu khá chi tiết về cách Setup Swagger, tuy nhiên mình thấy 1 số điểm chưa thực sự “dry” code cho lắm, do đó mình sẽ custom lại Trees (cấu trúc) của Swagger trong Project của mình 1 chút để tận dụng được những cái sài chung (tái sử dụng code í mà) như kiểu các Paramerter hay được gọi đi gọi là hoặc là các Response phổ biến (lỗi 404 hay 500 chẳng hạn). Đồng thời cũng giúp chúng ta dễ dàng mở rộng code khi cần thiết trong tương lai.

    Cấu trúc thư mục của Swagger khi đó sẽ như thế này:

    So sánh với tài liệu trên Repo của Swagger-Blocks thì cách tổ chức của mình có 1 vài điểm mà cá nhân mình nghĩ sẽ rành mạch và rõ ràng hơn.

    • Theo Swagger hướng dẫn thì mỗi Documents sẽ ứng với 1 Controller, cách viết này khá dễ hiểu, nhưng các bạn có thế dễ dàng nhận ra là Controller sẽ bị phình to “cực kỳ” nhanh nếu đặt Docs trong đó. Và Controller cũng không phải là là 1 nơi lý tưởng để xử lý Docs. Do đó, chúng ta hãy tách ra thành 1 Module riêng biệt – chuyển xử lý Docs. Cụ thể ở đây mình sẽ để vào trong thư mục concern/swagger rồi sau đó Include lại vào Controller.
    • Sẽ có rất nhiều Parameter dùng chung, ví dụ: userID được dùng chung khi get thông tin của User cũng như update thông tin user chẳng hạn. Do đó mình tạo ra 1 file chúng tôi để chứa những thứ dùng chung, khi cần dùng thì sẽ include lại vào file Docs (ở đây là user_api.rb)
    • Tương tự, sẽ có rất nhiều Response Error được dùng chung, kiểu lỗi 401 – not authorize hay là 404 – not found Records do đó mình tạo ra 1 file error_response.rb để viết chung, khi cần lại include vào file chứa Docs (ở đây là user_api.rb)
    • Response Success 200 tuy mỗi API sẽ trả về 1 thông tin khác nhau, nhưng không phải là không có điểm chung. Chẳng hạn, các API sau đều trả về thông tin của User sau khi Request thành công đó là: API show, API edit thông tin của User và API login. Do đó, chúng ta phải tìm cách tái sử dụng Code. May thay, với Swagger chúng ta có thể sử dụng $ref để gọi tới 1 schema được định nghĩa trước đó (ở đây là: user_schema.rb trong modes/concern/swagger)

    Chú ý cần tạo Router cho Documents để còn biết URL mà xem trên trình duyệt.

    Sau khi tạo Router, thì chúng ta cũng tạo ra 1 controller ứng với router này và định nghĩa các thông số cơ bản của API Documents như:

    • Version Swagger sử dụng -Tittle, Description của API
    • Đường dẫn mặc định của API
    • Kiểu dữ liệu sinh ra của API (thường là Json hoặc có thể là XML) ….

    Trong method index của api_docs_controller các bạn nhớ gọi method để render ra những thông tin API mà mình muốn viết Docs.

    Đến đây là các bạn có thể bật server lên và vào URL: localhost:3000/api_docs.json để xem thanh quả rồi.

    Chúng ta sẽ dùng gem swagger_ui_engine và config 1 chút để có giao diện Swagger UI cho dữ liệu json mình vừa tạo ra ở bên trên như sau:

    Xong. Tới đây bạn có thể restart lại server, truy cập lại URL localhost:3000/api_docs để thấy thành quả.

    --- Bài cũ hơn ---

  • Giới Thiệu Tool Swagger Ui
  • Học Kiểm Thử Api Trong 10 Phút
  • Cách Tạo Api Với Rails (Phần 2) Viết Test Case
  • How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)
  • Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu
  • Restful Api Là Gì? Cách Thiết Kế Restful Api

    --- Bài mới hơn ---

  • Bài 68: Xây Dựng Web Service Dùng Api Restful Service(Phần 1)
  • Tạo Một Restful Api Đơn Giản Với Php Và Mysql
  • Hướng Dẫn Xây Dựng Web Api Entity Framework 2022
  • Hướng Dẫn Cách Tạo App Mobile Trong 10 Phút Đơn Giản Nhất
  • Hướng Dẫn Cách Tính Ngân Sách Phát Triển Cho Từng Loại Ứng Dụng
  • Có thể nói nguyên lí và cấu trúc dữ liệu RESTful được biết đến rộng rãi trong giới lập trình web nói chung và lập trình ứng dụng nói riêng.

    Có thể nói bản thân REST không phải là một loại công nghệ. Nó là phương thức tạo API với nguyên lý tổ chức nhất định. Những nguyên lý này nhằm hướng dẫn lập trình viên tạo môi trường xử lý API request được toàn diện.

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

    RESTful API là một tiêu chuẩn dùng trong việc thiết kế API cho các ứng dụng web (thiết kế Web services) để tiện cho việc quản lý các resource. Nó chú trọng vào tài nguyên hệ thống (tệp văn bản, ảnh, âm thanh, video, hoặc dữ liệu động…), bao gồm các trạng thái tài nguyên được định dạng và được truyền tải qua HTTP.

    API ( Application Programming Interface) là một tập các quy tắc và cơ chế mà theo đó, một ứng dụng hay một thành phần sẽ tương tác với một ứng dụng hay thành phần khác. API có thể trả về dữ liệu mà bạn cần cho ứng dụng của mình ở những kiểu dữ liệu phổ biến như JSON hay XML.

    REST ( REpsentational State T ransfer) là một dạng chuyển đổi cấu trúc dữ liệu, một kiểu kiến trúc để viết API. Nó sử dụng phương thức HTTP đơn giản để tạo cho giao tiếp giữa các máy. Vì vậy, thay vì sử dụng một URL cho việc xử lý một số thông tin người dùng, 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à một tiêu chuẩn dùng trong việc thiết kế các API cho các ứng dụng web để quản lý các resource. RESTful là một trong những kiểu thiết kế API được sử dụng phổ biến ngày nay để cho các ứng dụng (web, mobile…) khác nhau giao tiếp với nhau.

    Chức năng quan trọng nhất của REST là quy định cách sử dụng các HTTP method (như GET, POST, PUT, DELETE…) và cách định dạng các URL cho ứng dụng web để quản các resource. RESTful không quy định logic code ứng dụng và không giới hạn bởi ngôn ngữ lập trình ứng dụng, bất kỳ ngôn ngữ hoặc framework nào cũng có thể sử dụng để thiết kế một RESTful API.

    RESTful hoạt động như thế nào?

    • GET (SELECT): Trả về một Resource hoặc một danh sách Resource.
    • POST (CREATE): Tạo mới một Resource.
    • PUT (UPDATE): Cập nhật thông tin cho Resource.
    • DELETE (DELETE): Xoá một Resource.

    Những phương thức hay hoạt động này thường được gọi là CRUD tương ứng với Create, Read, Update, Delete – Tạo, Đọc, Sửa, Xóa.

    Hiện tại đa số lập trình viên viết RESTful API giờ đây đều chọn JSON là format chính thức nhưng cũng có nhiều người chọn XML làm format, nói chung dùng thế nào cũng được miễn tiện và nhanh.

    Authentication và dữ liệu trả về

    RESTful API không sử dụng session và cookie, nó sử dụng một access_token với mỗi request. Dữ liệu trả về thường có cấu trúc như sau:

    { "data" : { "id": "1", "name": "TopDev" } }

    Status code

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

    • 200 OK – Trả về thành công cho những phương thức GET, PUT, PATCH hoặc DELETE.
    • 201 Created – Trả về khi một Resouce vừa được tạo thành công.
    • 204 No Content – Trả về khi Resource xoá thành công.
    • 304 Not Modified – Client có thể sử dụng dữ liệu cache.
    • 400 Bad Request – Request không hợp lệ
    • 401 Unauthorized – Request cần có auth.
    • 403 Forbidden – bị từ chối không cho phép.
    • 404 Not Found – Không tìm thấy resource từ URI
    • 405 Method Not Allowed – Phương thức không cho phép với user hiện tại.
    • 410 Gone – Resource không còn tồn tại, Version cũ đã không còn hỗ trợ.
    • 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

    Nên sử dụng Version

    Luôn sử dụng version để khi bạn cần nâng cấp API mà vẫn hỗ trợ các API cũ.

    Xây dựng API với Laravel

    Lấy việc xây dựng api trên Laravel để làm ví dụ, trước khi đi vào ta tổng quan về Http Request.

    HTTP Request

    HTTP request có tất cả 9 loại method , 2 loại được sử dụng phổ biến nhất là GET và POST

    • GET: được sử dụng để lấy thông tin từ server theo URI đã cung cấp.
    • HEAD: giống với GET nhưng response trả về không có body, chỉ có header.
    • POST: gửi thông tin tới sever thông qua các biểu mẫu http.
    • PUT: ghi đè tất cả thông tin của đối tượng với những gì được gửi lên.
    • PATCH: ghi đè các thông tin được thay đổi của đối tượng.
    • DELETE: xóa tài nguyên trên server.
    • CONNECT: thiết lập một kết nối tới server theo URI.
    • OPTIONS: mô tả các tùy chọn giao tiếp cho resource.
    • TRACE: thực hiện một bài test loop – back theo đường dẫn đến resource.

    RESTful Route

    Viết Api thì sẽ khai báo router vào file routes/api.php thay vì sử dụng file routes/web.php. Các setting mặc cho file api.php trong laravel:

    • Url: những route được khai báo trong file này mặc định có pfix url là api (ví dụ: topdev.vn/api/products)
    • Middleware: mặc định sẽ được gán Middleware Group là api, trong file app/Http/Kernel sẽ thấy 2 middleware thuộc Middleware Group: api là throttle (giới hạn request / time) và bindings (model binding).

    Có thể tùy chỉnh giá trị mặc định này trong method mapApiRoutes trong file app/Providers/RouteServiceProvider.php

    Tạo các route để thực hiện các thao tác như CRUD (Create, Read, Update, Delete):

    // Lấy list sản phẩm // Lấy detail sản phẩm theo id // Add sản phẩm // Update info sản phẩm theo id # Sử dụng put nếu update toàn bộ các field # Sử dụng patch nếu update 1 vài field // Xóa sản phẩm theo id

    Mặc định route đã được gán middleware bindings, nếu muốn sử dụng model binding trong controller thì chúng ta sửa lại tham số trong route như sau:

    Ngoài ra trong laravel cũng hỗ trợ chúng ta 1 cách khai báo ngắn gọn hơn:

    //Nếu không muốn sử dụng toàn bộ method trong apiResource mọi người có thể chỉ định sử dụng 1 vài method bằng hàm only //Hoặc nếu muốn loại bỏ đi 1 số method không dùng thì có thể sử dụng hàm except

    Resource Controllers

    Tương ứng với các Route RESTful đã khai báo ở trên, đặc biệt nếu dùng method apiResource thì laravel cũng hỗ trợ các method xử lí tương ứng trong controller.

    Để tạo ra Resource Controllers chúng ta chạy lệnh sau

    php artisan make:controller Api/ProductController -api

    File ProductController tạo ra sẽ như sau<?php namespace AppHttpControllersApi; use IlluminateHttpRequest; use AppHttpControllersController; class ProductController extends Controller { /** * Display a listing of the resource. * * @return IlluminateHttpResponse */ public function index() { // } /** * Store a newly created resource in storage. * * @param IlluminateHttpRequest $request * @return IlluminateHttpResponse */ public function store(Request $request) { // } /** * Display the specified resource. * * @param int $id * @return IlluminateHttpResponse */ public function show($id) { // } /** * Update the specified resource in storage. * * @param IlluminateHttpRequest $request * @param int $id * @return IlluminateHttpResponse */ public function update(Request $request, $id) { // } /** * Remove the specified resource from storage. * * @param int $id * @return IlluminateHttpResponse */ public function destroy($id) { // } }

    Ngoài ra nếu muốn sử dụng model binding khi tạo Resource Controllers thì dùng lệnh bên dưới

    php artisan make:controller Api/ProductController --api --model=Models/Product

    File ProductController tạo ra sẽ như sau, chúng ta để ý tham số của các method show, update, destroy sẽ thay đổi 1 chút.

    <?php namespace AppHttpControllersApi; use AppModelsProduct; use IlluminateHttpRequest; use AppHttpControllersController; class ProductController extends Controller { /** * Display a listing of the resource. * * @return IlluminateHttpResponse */ public function index() { // } /** * Store a newly created resource in storage. * * @param IlluminateHttpRequest $request * @return IlluminateHttpResponse */ public function store(Request $request) { // } /** * Display the specified resource. * * @param AppModelsProduct $product * @return IlluminateHttpResponse */ public function show(Product $product) { // } /** * Update the specified resource in storage. * * @param IlluminateHttpRequest $request * @param AppModelsProduct $product * @return IlluminateHttpResponse */ public function update(Request $request, Product $product) { // } /** * Remove the specified resource from storage. * * @param AppModelsProduct $product * @return IlluminateHttpResponse */ public function destroy(Product $product) { // } }

    Demo 1 đoạn code đơn giản trong controller kết hợp với model binding và route apiResource khi xây dựng API:

    <?php namespace AppHttpControllersApi; use AppHttpControllersController; use AppModelsProduct; use IlluminateHttpRequest; class ProductController extends Controller { /** * Display a listing of the resource. * */ public function index() { return Product::all(); } /** * Store a newly created resource in storage. * * @param Request $request */ public function store(Request $request) { } /** * Display the specified resource. * * @param Product $product * @return Product */ public function show(Product $product) { return $product; } /** * Update the specified resource in storage. * * @param Request $request * @param Product $product * @return bool */ public function update(Request $request, Product $product) { } /** * Remove the specified resource from storage. * * @param Product $product * @throws Exception */ public function destroy(Product $product) { } }

    Mặc định khi sử dụng route apiResource thì dữ liệu trả về sẽ tự động được chuyển sang kiểu JSON và sẽ có status tương ứng nên chỉ cần return dữ liệu ra là được.

    Còn nếu muốn tùy biến status trả về thì có thể tham khảo cách phía dưới có sử dụng class IlluminateHttpResponse để lấy status thay vì fix giá trị vào ví dụ như HTTP_OK tương ứng sẽ là 200

    <?php namespace AppHttpControllers; use AppModelsProduct; use IlluminateHttpRequest; use IlluminateHttpResponse; class ProductController extends Controller { /** * Display a listing of the resource. * * @return IlluminateHttpJsonResponse */ public function index() { $products = Product::all(); } } Eloquent Resources

    Khi xây dựng API, bạn có thể cần transform dữ liệu từ controller trước khi trả về cho người dùng ứng dụng của bạn, laravel cũng đã hỗ trợ điều này với Eloquent Resources

    Để tạo ra 1 class chuyển đổi chúng ta chạy lệnh sau

    php artisan make:resource Product

    File app/Http/Resources/Product.php sẽ có nội dung như sau

    <?php namespace AppHttpResources; use IlluminateHttpResourcesJsonJsonResource; class Product extends JsonResource { /** * Transform the resource into an array. * * @param IlluminateHttpRequest $request * @return array */ public function toArray($request) { return parent::toArray($request); } }

    Mình sẽ tùy chỉnh dữ liệu trả về là chỉ có title và price

    <?php namespace AppHttpResources; use IlluminateHttpResourcesJsonJsonResource; class Product extends JsonResource{ /** * Transform the resource into an array. * * @param IlluminateHttpRequest $request * @return array */ public function toArray($request){ return [ ]; } }

    Ở controller thì mình sẽ sửa lại như sau

    <?php namespace AppHttpControllersApi; use AppHttpControllersController; use AppModelsProduct; use IlluminateHttpRequest; use AppHttpResourcesProduct as ProductResource; class ProductController extends Controller{ /** * Display a listing of the resource. * */ public function index(){ $products = Product::all(); return ProductResource::collection($products); } /** * Store a newly created resource in storage. * * @param Request $request */ public function store(Request $request){ return new ProductResource($product); } /** * Display the specified resource. * * @param Product $product * @return Product */ public function show(Product $product){ return new ProductResource($product); } /** * Update the specified resource in storage. * * @param Request $request * @param Product $product * @return bool */ public function update(Request $request, Product $product){ } /** * Remove the specified resource from storage. * * @param Product $product * @throws Exception */ public function destroy(Product $product){ } }

    Authorization

    Hiện tại có 3 cơ chế Authorize chính:

    Tùy thuộc vào service của bạn, mà hãy chọn loại Authorize có mức độ phù hợp, cố gắng giữ nó càng đơn giản càng tốt.

    CORS Policy

    Viết API thì cũng cần chú ý về CORS là gì?

    API Document

    API document là một phần tương tự như Unit Test vậy - lấy ngắn để nuôi dài.

    • Mô tả đầy đủ về params request: gồm những params nào, datatype, require hay optional.
    • Nên đưa ra các ví dụ về HTTP requests và responses với data chuẩn.
    • Cập nhật Docs thường xuyên, để sát nhất với API có bất cứ thay đổi gì.
    • Format, cú pháp cần phải nhất quán, mô tả rõ ràng, chính xác.

    --- Bài cũ hơn ---

  • Một Vài Kinh Nghiệm Viết Api
  • Viết Api Đầu Tiên Của Bạn Bằngvà Express: Tìm Hiểu Về Rest Api
  • Restful Api Cho Người Bắt Đầu
  • Bài 1: Cách Tạo Ứng Dụng Web Api
  • Cách Viết Và Cấu Trúc Chi Tiết Một Bài Báo Khoa Học
  • 10 Cách Tốt Nhất Để Viết Các Rest Api Node.js

    --- Bài mới hơn ---

  • Kết Nối Rest Api Bằng Retrofit Trong Android
  • Cách Sử Dụng Api WordPress Rest
  • Sử Dụng WordPress Rest Api Toàn Tập
  • Hướng Dẫn Tạo Secure Rest Api Trong
  • Cách Test Api Như Thế Nào?
  • Bài viết được dịch từ: https://blog.risingstack.com/10-best-practices-for-writing-node-js-rest-apis/

    Một trong những trường hợp sử dụng thông dụng nhất của chúng tôi là viết các RESTful API. Khi chúng tôi đang hỗ trợ khách hàng bằng cách tìm các vấn đề trong ứng dụng của họ với Trace (công cụ giám sát chúng tôi thì phát hiện ra rằng có rất nhiều các developer đang gặp vấn đề với REST API. Do đó, tôi mong rằng các cách chúng tôi sử dụng với RisingStack sẽ giúp được bạn:

    1. Sử dụng phương thức HTTP và các API Route

    Hãy tưởng tượng rằng bạn đang xây dựng một RESTful API chúng tôi để tạo, cập nhật, gọi thông tin hay xóa người dùng. Với các tính năng đó HTTP đã cung cấp một bộ đầy đủ các phương thức: và.

    Cách tối ưu nhất là các API route của bạn chỉ nên sử dụng danh từ như là các định danh tài nguyên. Các route khi đó sẽ trông như thế này:

    • POST /user hay PUT /user:/id để tạo người dùng mới.
    • GET /user để lấy danh sách người dùng.
    • GET /user/:id để lấy thông tin của một người dùng.
    • PATCH /user/:id để sửa một bản ghi người dùng đã có.
    • DELETE /user/:id để xóa một người dùng.

    Các API route của bạn chỉ nên sử dụng danh từ như là các định danh tài nguyên.

    2. Sử dụng mã status HTTP đúng

    Nếu có gì xảy ra khi server đang xử lý một request, bạn cần thiết lập đúng mã status trong response trả về:

    • 2xx, nếu không có lỗi (thành công).
    • 3xx, nếu tài nguyên đã bị gỡ bỏ.
    • 4xx, nếu request không được thực hiện do lỗi client.
    • 5xx, nếu có lỗi ở phía API (một ngoại lệ nào đó xảy ra,…).

    Nếu bạn sử dụng Expss, thiết lập mã status khá dễ dàng: res.status(500).send({error: 'Internal server error happened'}). Với Restify: res.status(201).

    Bạn có thể xem danh sách đầy đủ các mã status ở đây.

    3. Sử dụng các header HTTP để gửi metadata

    Để đính kèm các metadata vào payload bạn sắp gửi, sử dụng HTTP header. Các header sẽ bao gồm các thông tin:

    Đây là một danh sách các header HTTP đã chuẩn hóa.

    Nếu bạn cần thiết lập bất cứ metadata custom nào trong header, hãy thêm tiền tố X vào phía trước. Ví dụ, nếu bạn đang sử dụng CSRF token, cách thông thường (nhưng không chuẩn) là đặt tên kiểu X-Csrf-Token. Tuy nhiên, theo RFC 6648 thì sẽ gây khó hiểu. Với các API mới không nên sử dụng các tên header dễ gây xung đột với các ứng dụng khác. Ví dụ, OpenStack sẽ tự động thêm tiền tố vào header với OpenStack:

    Chú ý rằng các chuẩn HTTP không định nghĩa bất cứ giới hạn kích cỡ nào trong header. Tuy nhiên chúng tôi (kể từ lúc viết bài này) đã buộc object header nhận một giới hạn kích thước là 80kB cho lý do thực tế.

    Không cho phép kích thước tổng của các HTTP header (bao gồm các mã status) vượt quá HTTP_MAX_HEADER_SIZE. Điều này giúp bảo vệ các embedder khỏi các cuộc tấn công từ-chối-dịch-vụ, khi kẻ tấn công sẽ gửi các header không-kết-thúc cho các embedder lưu giữ buffering.

    4. Chọn đúng framework cho REST API Node.js

    Expss, Koa hay Hapi

    Expss, Koa hay Hapi có thể được sử dụng để tạo ra các ứng dụng nền web, chúng hỗ trợ templating và rendering. Nếu ứng dụng của bạn cần cung cấp dịch vụ phía người dùng, hãy thử dùng một trong số chúng và tận hưởng thành quả.

    Restify

    Ở một khía cạnh khác, Restify tập trung hoàn toàn vào việc giúp bạn xây dựng các dịch vụ REST. Restify tồn tại để giúp bạn xây dựng các dịch vụ API “chuẩn” đáng kể, dễ bảo trì. Restify cũng đi kèm với công cụ hỗ trợ tự động DTrace.

    Về mức độ phủ sóng thì Restify đang được sử dụng trong rất nhiều các ứng dụng, điển hình như npm hay Netflix.

    Restify tồn tại để giúp bạn xây dựng các dịch vụ API “chuẩn” đáng kể, dễ bảo trì.

    @RisingStack

    5. Test black-box các REST API

    Một trong những cách hay nhất để test các REST API là xem chúng như các black-box.

    Black-box test là phương pháp kiểm thử chức năng của ứng dụng mà không cần quan tâm đến cấu trúc bên trong của nó hay cách nó hoạt động. Do đó, sẽ không cần mock dependency nào, hệ thống sẽ được test như một thể duy nhất.

    Để giúp bạn test các REST API theo phương pháp black-box này, ta sẽ sử dụng module supertest.

    Có lẽ bạn sẽ thắc mắc: làm thế nào để phổ biến dữ liệu vào trong database phục vụ cho các REST API?

    Thông thường, test thường được viết làm sao để chúng tạo ra càng ít các giả định cho trang thái hệ thống càng tốt. Tuy vậy, trong một vài bối cảnh bạn cần biết chính xác trạng thái của hệ thống, bạn có thể tạo các assertion và đạt được mức độ test cao hơn.

    Tùy thuộc vào nhu cầu của bạn, bạn có thể phổ biến cơ sở dữ liệu với các dữ liệu test theo một trong các cách sau:

    • Chạy kịch bản test black-box theo một tập con đã biết của dữ liệu production.
    • Phổ biến database với dữ liệu thủ công trước khi chạy các test case.

    Dĩ nhiên, black-box test không đồng nghĩa với việc bạn không cần viết unit test. Trong hầu hết các trường hợp, bạn vẫn cần viết unit test cho các API.

    6. JWT – Xác thực phi trạng thái

    Các API phải là phi trạng thái, bởi vậy xác thực cũng tương tự. JWT (Json Web Token) chính là ý tưởng. JWT gồm 3 phần:

    • Header: chứa kiểu của token, thuật toán hash.
    • Payload: Chứa các yêu cầu.
    • Signature (JWT không mã hóa payload mà chỉ kí xác thực).

    Thêm xác thực loại JWT vào ứng dụng khá đơn giản và nhanh chóng:

    Sau khi thêm, endpoint API đã được bảo vệ với JWT. Để truy cập vào các endpoint được bảo vệ, bạn cần phải cung cấp token trong trường header Authorization:

    Hãy chú ý một điều rằng module JWT trên không phụ thuộc bất cứ lớp database nào, do tất cả token JWT có cơ chế tự xác thực, và chúng còn bao gồm cả giá trị thời gian sống.

    Ngoài ra, bạn phải luôn luôn chắc chắn rằng tất cả các API endpoint trong ứng dụng sẽ chỉ được truy cập thông qua kết nối bảo mật sử dụng HTTPS.

    Trong bài viết trước, chúng tôi đã giải thích chi tiết về phương pháp xác thực web. Tôi khuyến nghị các bạn hãy tìm hiểu thêm.

    7. Sử dụng các request có điều kiện

    Các request có điều kiện là các request HTTP được thực thi theo các cách khác nhau, phụ thuộc vào các header HTTP cụ thể. bạn có thể xem các header này như là điều kiện tiên quyết: nếu chúng gặp nhau, các request sẽ được thực thi theo các cách khác nhau.

    Các request có điều kiện là các request HTTP được thực thi theo các cách khác nhau, phụ thuộc vào các header HTTP cụ thể

    @RisingStack

    Các header này sẽ cố gắng kiểm tra liệu một phiên bản tài nguyên được lưu trữ trên server có trùng với phiên bản của cùng một tài nguyên hay không. Vì lý do này, các header có thể là:

    • Timestamp của lần thay đổi gần nhất.
    • Một tag nào đấy, khác nhau tùy vào phiên bản.

    Chúng chính là:

    • Last-Modified ( để chỉ ra lần gần nhất dữ liệu được chỉnh sửa ).
    • Etag ( để chỉ ra tag ).
    • If-Modified-Since (sử dụng với header Last-Modified ).
    • If-None-Match (sử dụng với header Etag ).

    Client có thể thiết lập header If-Modified-SinceIf-None-Match một lần khi nó cố gắng gửi request với cùng tài nguyên. Nếu response trả về là giống nhau, server chỉ đơn giản là phản hồi lại với mã status 304 - Not Modified và không gửi lại tài nguyên nữa.

    8. Quản lý giới hạn rate (rate limiting)

    Rate limiting được sử dụng để điều khiển việc một cunsumer có thể gửi đến API bao nhiêu request.

    Để nói với API có bao nhiêu request đã được gửi, trong header hãy thiết lập như sau:

    • X-Rate-Limit-Limit: số lượng các request được cho phép trong một khoảng thời gian cho trước.
    • X-Rate-Limit-Remaining: the number of requests remaining in the same interval. số lượng các request cong lại trong cùng khoảng thời gian.
    • X-Rate-Limit-Reset: thời gian mà rate limit được thiết lập.

    Phần lớn các framework HTTP hỗ trợ bằng các công cụ bên ngoài hay là các plugin. Ví dụ, nếu bạn sử dụng Koa, hãy thử package koa-ratelimit.

    Chú ý rằng thời gian window có thể thay đổi tùy vào các nhà cung cấp API khác nhau – ví dụ đối với Github là 1 giờ, trong khi Twitter là 15 phút.

    9. Tạo các document API đúng chuẩn

    Các API được viết ra để mọi người có thể sử dụng chúng, hưởng lợi ích từ chúng. Do đó việc cung cấp các document đi kèm với các REST API là điều tối cần thiết.

    Các project open-source sau đây có thể giúp bạn tạo ra các document cho API:

    Nếu bạn muốn sử dụng sản phẩm đã host, bạn có thể dùng Apiary.

    10. Đừng quên tương lai sáng lạn của API

    Trong vài năm vừa qua, hai ngôn ngữ truy vấn lớn cho các API đã mọc lên: GraphQL của Facebook và Falcor của Netflix. Tại sao ta lại cần chúng đến thế?

    Tưởng tượng một request tài nguyên RESTful như sau:

    Nếu bạn có dự định bắt đầu phát triển một REST API chúng tôi hoặc tạo một phiên bản mới của API cũ, chúng tôi đã thu thập 4 ví dụ thực tế để giúp bạn:

    Tôi mong là qua bài viết này, các bạn đã có một cái nhìn tổng thể về các API, tại sao các API nên được viết bằng Node.js.

    Nguồn Techtalk.vn

    --- Bài cũ hơn ---

  • WordPress Rest Api Là Gì? Hướng Dẫn Sử Dụng WordPress Rest Api
  • Bài Hướng Dẫn WordPress Rest Api
  • Rest Api Là Gì? Giới Thiệu Và Cách Sử Dụng WordPress Rest Api Cơ Bản
  • Tạo Restful Api Web Service Trong Java Spring Boot
  • Stream Api Là Gì? Stream Api Trong Java 8
  • Viết Api Document Với Apidocjs

    --- Bài mới hơn ---

  • Cách Gõ Biểu Tượng Logo Apple
  • Mẹo Làm Bài Thi B1 Preliminary (Pet) Format 2022 (2): Phần 1 Bài Thi Viết – Writing – Aspect
  • Cách Viết Bản Kiểm Điểm Nói Chuyện Trong Giờ Học
  • Cách Viết Thư Xin Lỗi Bằng Tiếng Nhật Gửi Ngoài Công Ty
  • Đi Học Muộn, Học Sinh Viết Bản Kiểm Điểm “bá Đạo” Khiến Dân Tình Cườ
  • Document là thứ rất quan trọng khi bàn giao một dự án hay cần tham khảo để bảo trì, phát triển dự án đó. Một số bạn dev sẽ nói mình viết code đẹp rồi, cứ vào đọc là hiểu ngay cần gì làm doc và thẳng thừng nói không với doc. Nhưng khi download một source code về, nhận code từ dev khác hay vào maintain một project thì khóc ròng vì không hiểu người ta viết gì cả. Vậy nên:

    1. Nếu bạn định code cái gì, hãy dành thời gian ra viết một chút document cho nó

    2. Nếu bạn không cập nhật document thì đừng viết nó ra

    Với API, dù bạn viết code đẹp thế nào mà không có gì cho client tham khảo ngoài một API mẫu thì khối API bạn viết sẽ sớm trở thành thảm họa với những lỗi kinh điển như: sai kiểu dữ liệu gửi nhận, sai mã lỗi, tốn thời gian support client, mất kiểm soát khi nâng cấp API version… sau đó thì kiểu gì bạn cũng phải ngồi viết document.

    npm install apidoc -g

    Các thức hoạt động

    Folder api-document-output là output của chương trình được generate tự động, bạn không cần đụng tới nó, chỉ cần mở file index.html để xem kết quả.

    Bắt đầu viết doc như sau, tạo một file có đuôi cùng với ngôn ngữ bạn dùng để viết API, trong trường hợp này là .js, viết toàn bộ thông tin về một API theo mẫu thế này:

    /** * @api {get} /user/:id Request User information * @apiName GetUser * @apiGroup User * * @apiParam {Number} id Users unique ID. * * @apiSuccess {String} firstname Firstname of the User. * @apiSuccess {String} lastname Lastname of the User. * * @apiSuccessExample Success-Response: * HTTP/1.1 200 OK * { * "firstname": "John", * "lastname": "Doe" * } * * @apiError UserNotFound The id of the User was not found. * * @apiErrorExample Error-Response: * HTTP/1.1 404 Not Found * { * "error": "UserNotFound" * } */

    apidoc -i api-document-source/ -o api-document-output/

    Với param -i, -o đơn giản là input folder, output folder. Sau đó mở file index.html trong folder out put để xem kết quả.

    Giao diện đơn giản trình bày tất cả API trong một trang, navigate bằng menu bên trái, toàn bộ chi tiết trình bày ở giữa trang

    Happy documentation 🙂

    --- Bài cũ hơn ---

  • Cách Đổi Font Chữ Trên Story Facebook Siêu Dễ Ai Cũng Làm Được
  • Cách Làm Menu Đẹp Siêu Đơn Giản Mà Ấn Tượng
  • Cách Viết Chữ Kiểu Trên Facebook Trên Điện Thoại
  • Phần Mềm Tạo Chữ Ký Online Cực Đẹp Theo Tên Của Bạn
  • Mẫu Chữ Ký Đẹp
  • Cách Test Api Như Thế Nào?

    --- Bài mới hơn ---

  • Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu
  • How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)
  • Cách Tạo Api Với Rails (Phần 2) Viết Test Case
  • Học Kiểm Thử Api Trong 10 Phút
  • Giới Thiệu Tool Swagger Ui
  • Sau khi đọc xong series “test API với Postman” của mình, các bạn có thể nắm được cái kiến thức cơ bản của API và các chức năng của Postman đem lại. Nhưng cách sắp xếp test và viết Testcase cho API như thế nào thì vẫn có vẻ chưa thông lắm, nên hôm nay mình sẽ viết 1 bài về cách test API như thế nào cho hợp lý.

    Ví dụ: Tôi muốn check API update_profile gồm 2 trường Name và Birthday. Trong đó trường Name là bắt buộc và phải lớn hơn 4 ký tự. Trường Birthday thì không bắt buộc nhập.

    Cách xử lý của Server và Client (có thể không giống với cty bạn):

    1. User vào màn hình Profile, sửa lại 2 trường Name và Birthday.
    2. User ấn vào nút Update Profile (Code ở client sẽ check điều kiện của trường Name, nếu đúng thì submit gửi API, gọi là request, nếu sai sẽ hiện thông báo tương ứng).
    3. Thông tin mới gồm Name và Birthday theo phong bì thư của API cập bến Server.
    4. Server đọc thư và check điều kiện lại 1 lần nữa.
    5. Nếu các thông tin Name và Birthday đều Valid thì 2 thông tin đó được cập nhật vào Database.
    6. Server trả lại thông tin, gọi là response, về lại cho client thông báo rằng nó đã cập nhật thành công.
    7. User nhìn thấy Name và Birthday của mình đã được thay đổi ở màn hình Profile.

    Khi thực hiện test API, chính là việc chúng ta test các bước 4, 5 và 6. Dó đó, với 1 API đơn lẻ, chúng ta sẽ check 2 phần chính:

    – tạm gọi là Syntax Testing (Validate dữ liệu – bước 4 + bước 6)

    – và Funtional Testing (Test business logic – bước 5 và 6).

    Syntax Testing

    Loại này sẽ tập trung vào cái Method check điều kiện: Accept với data đúng và Reject với data sai hay không. Một vài ví dụ:

    • Bỏ trống trường bắt buộc → Trong Response sẽ phải có thông báo lỗi, các thông tin khác không được cập nhật. Server không thực hiện 1 business logic nào cả.
    • Bỏ trống trường không bắt buộc → Không có lỗi gì cả, Server vẫn thực hiện business logic.
    • Điền các thông tin sai kiểu định dạng, ví dụ trường thời gian lại điền chữ → Trong Response sẽ phải có thông báo lỗi…

    Chốt lại: Cái này giống hệt như những trường hợp Validate dữ liệu, chúng ta vẫn hay làm hàng ngày.

    Functional Testing

    Loại này check các Method xử lý dữ liệu và thực hiện 1 chức năng có đúng hay không. Ví dụ:

    • Giá là X và số phần trăm discount là Y thì số tiền phải trả là X*(1-Y) hay không → Nó chính là việc test Method tính toán với các tham số X và Y mà thôi. Việc thực hiện business logic có thể không lưu kết quả vào DB.
    • Việc Update trường Name ở ví dụ ban đầu có được lưu vào DB hay không? → mở DB ra và check kết quả.
    • Yêu cầu trả về thông tin của những user có tên là “Nam” → Vào DB thực hiện câu Query và so sánh với Response xem 2 kết quả có khớp nhau hay ko…

    Test scenarios

    Cuối cùng là ta ghép các API lại với nhau sẽ nó có bị lỗi ở đâu không? Chỗ này chính là những cái Test Suite, gộp nhiều Test Case lại.

    Ví dụ như hình:

    1. Khi sử dụng Postman, hãy để mỗi trường hợp là 1 API riêng biệt, không test đè lên nhau, sau khó kiểm soát và không tạo được test case cho automation.
    2. Để không phải căng mắt check từng response của các trường hợp đơn lẻ, hãy đọc lại bài 9.

    Bài viết dựa trên bài ” API testing best practices ” của Bas Dijkstra

    API Testing với Postman (Phần 12) – Run Test Suites từ Runner

    --- Bài cũ hơn ---

  • Hướng Dẫn Tạo Secure Rest Api Trong
  • Sử Dụng WordPress Rest Api Toàn Tập
  • Cách Sử Dụng Api WordPress Rest
  • Kết Nối Rest Api Bằng Retrofit Trong Android
  • 10 Cách Tốt Nhất Để Viết Các Rest Api Node.js
  • Viết Api Đầu Tiên Của Bạn Bằngvà Express: Tìm Hiểu Về Rest Api

    --- Bài mới hơn ---

  • Một Vài Kinh Nghiệm Viết Api
  • Restful Api Là Gì? Cách Thiết Kế Restful Api
  • Bài 68: Xây Dựng Web Service Dùng Api Restful Service(Phần 1)
  • Tạo Một Restful Api Đơn Giản Với Php Và Mysql
  • Hướng Dẫn Xây Dựng Web Api Entity Framework 2022
  • Tìm hiểu về REST và RESTful API

    Nếu bạn đã từng dành gian cho việc phát triển web hiện đại, bạn sẽ gặp các thuật ngữ như REST và API. Nếu bạn đã từng nghe về các thuật ngữ này hoặc từng làm việc với các API nhưng không hiểu đầy đủ về cách chúng hoạt động hoặc cách xây dựng API của riêng bạn, thì loạt bài này là dành cho bạn.

    Trong loạt bài hướng dẫn này, chúng ta sẽ bắt đầu với cái nhìn tổng quan về các nguyên tắc và khái niệm REST. Sau đó, chúng ta sẽ tiếp tục tạo API cho riêng mình, chạy trên máy chủ chúng tôi Expss và kết nối với cơ sở dữ liệu MySQL. Sau khi hoàn thành loạt bài này, bạn sẽ có khả năng xây dựng API của riêng mình hoặc đi sâu tìm hiểu tài liệu của một API có sẵn.

    Điều kiện tiên quyết

    Để nắm bắt tốt hướng dẫn này, bạn nên có một số kiến ​​ thức cơ bản về dòng lệnh, biết các nguyên tắc cơ bản của JavaScript và cài đặt chúng tôi toàn cục.

    REST và RESTful API là gì?

    Repsentational State Transfer, hoặc REST, mô tả một kiểu kiến ​​trúc cho các dịch vụ web. REST bao gồm một tập hợp các tiêu chuẩn hoặc các ràng buộc để chia sẻ dữ liệu giữa các hệ thống khác nhau và các hệ thống cài đặt REST được gọi là RESTful. REST là một khái niệm trừu tượng, không phải là ngôn ngữ, framework hoặc kiểu phần mềm nào đó.

    REST giống như một bộ sưu tập vinyl so với sử dụng dịch vụ phát nhạc trực tuyến. Với bộ sưu tập vinyl vật lý, mỗi bản ghi phải được nhân lên toàn bộ để chia sẻ và phân phối các bản sao. Tuy nhiên, với một dịch vụ phát trực tuyến, cùng một bản nhạc có thể được chia sẻ vĩnh viễn thông qua một tham chiếu đến dữ liệu như tiêu đề bài hát. Trong trường hợp này, phát nhạc trực tuyến là một dịch vụ RESTful và bộ sưu tập vinyl là một dịch vụ không RESTful.

    API là viết tắt của Application Programming Interface, là giao diện cho phép các chương trình phần mềm giao tiếp với nhau. Một RESTful API đơn giản là một API tuân thủ các nguyên tắc và ràng buộc của REST. Trong một Web API, máy chủ nhận yêu cầu thông qua một URL endpoint và gửi về phản hồi, thường là dữ liệu ở định dạng chẳng hạn như JSON.

    Các Nguyên tắc của REST

    1. Uniform Interface: Giao diện của các thành phần phải giống nhau. Điều này có nghĩa là sử dụng URI tiêu chuẩn để xác định tài nguyên – nói cách khác, đường dẫn có thể được nhập vào thanh địa chỉ của trình duyệt.
    2. Client-Server: Có sự phân tách các mối liên hệ giữa server, nơi lưu trữ và xử lý dữ liệu và client, gửi yêu cầu và hiển thị phản hồi.
    3. Stateless Interactions: Tất cả các thông tin về mỗi yêu cầu được chứa trong mỗi yêu cầu riêng lẻ và không phụ thuộc vào trạng thái của session.
    4. Cacheable: Client và server có thể lưu cache tài nguyên.
    5. Layered System: Client có thể được kết nối với server cuối hoặc lớp trung gian chẳng hạn như một load-balancer.
    6. Code on Demand (Optional): Một client có thể tải về code, làm giảm khả năng hiển thị từ bên ngoài.

    Yêu cầu và Phản hồi

    Bạn đã quen với thực tế là tất cả các trang web đều có URL bắt đầu bằng http (hoặc https cho phiên bản bảo mật). HyperText Transfer Protocol, hay HTTP, là phương thức giao tiếp giữa client và server trên internet.

    Chúng ta thấy nó rõ nhất trong thanh URL của trình duyệt, nhưng HTTP có thể được sử dụng không chỉ cho yêu cầu các trang web từ server. Khi bạn truy cập một URL trên web, bạn thực sự đang thực hiện một yêu cầu (request) GET trên tài nguyên cụ thể đó và trang web mà bạn thấy là nội dung của phản hồi (response). Chúng ta sẽ tìm hiểu về GET và các kiểu yêu cầu khác trong giây lát nữa.

    HTTP hoạt động bằng cách mở kết nối TCP (Transmission Control Protocol) đến cổng server ( 80 cho http, 443 cho https) để thực hiện một yêu cầu và máy chủ lắng nghe và phản hồi với một trạng thái và body.

    Một yêu cầu phải bao gồm một URL, phương thức, thông tin header và body.

    Các phương thức yêu cầu

    Có bốn phương thức HTTP chính, còn được gọi là động từ HTTP, thường được sử dụng để tương tác với web API. Các phương thức này xác định hành động sẽ được thực hiện với bất kỳ tài nguyên nào.

    Các phương thức yêu cầu HTTP khá giống với mô hình của CRUD, viết tắt của Create, Update, Read, Delete. Mặc dù CRUD đề cập đến các hàm được sử dụng trong các thao tác cơ sở dữ liệu, chúng ta có thể áp dụng các nguyên tắc thiết kế đó cho các động từ HTTP trong RESTful API.

    GET là một hành động an toàn, chỉ đọc và sẽ không làm thay đổi trạng thái của server. Mỗi lần bạn nhập một URL trong trình duyệt của mình, chẳng hạn như https://www.google.com, bạn đang gửi một yêu cầu GET đến server của Google.

    POST được sử dụng để tạo một tài nguyên mới. Một ví dụ quen thuộc về POST là đăng ký người dùng trên trang web hoặc ứng dụng. Sau khi gửi form, một yêu cầu POST với dữ liệu người dùng có thể được gửi đến server, sau đó sẽ ghi thông tin đó vào cơ sở dữ liệu.

    PUT cập nhật tài nguyên hiện có, có thể được sử dụng để chỉnh sửa các cài đặt của người dùng có sẵn. Không giống như POST, PUTbình thường, có nghĩa là cùng một call có thể được thực hiện nhiều lần mà không tạo ra kết quả khác. Ví dụ, nếu bạn gửi cùng một yêu cầu POST để tạo người dùng mới trong cơ sở dữ liệu nhiều lần, nó sẽ tạo một người dùng mới có cùng dữ liệu cho mỗi yêu cầu bạn thực hiện. Tuy nhiên, sử dụng cùng một yêu cầu PUT trên cùng một người dùng sẽ liên tục tạo ra kết quả giống nhau.

    DELETE, giống như tên gọi của nó, sẽ xóa một tài nguyên hiện có.

    Code phản hồi

    Khi một yêu cầu được gửi từ client đến server, server sẽ gửi trả phản hồi HTTP, bao gồm siêu dữ liệu về phản hồi được gọi là header, cũng như body. Phần đầu tiên và quan trọng nhất của một phản hồi là code trạng thái, nó cho biết một yêu cầu có thành công hay không, có lỗi hoặc phải thực hiện một hành động khác hay không.

    Code phản hồi gặp nhiều nhất là 404, có nghĩa là Không tìm thấy. 404 là một phần của lớp code trạng thái 4xx, cho biết lỗi client. Có năm loại code trạng thái mà mỗi loại chứa một loạt các phản hồi khác nhau.

    Các phản hồi phổ biến khác mà bạn hay gặp là 301 Đã di chuyển vĩnh viễn, được sử dụng để chuyển hướng trang web sang URL mới và 500 Lỗi máy chủ nội bộ, đây là lỗi xuất hiện thường xuyên khi có sự cố bất ngờ xảy ra trên máy chủ khiến nó không thể thực hiện theo yêu cầu dự định

    200 OK là phản hồi cho biết yêu cầu đã thành công. Nó được sử dụng như một phản hồi khi gửi yêu cầu GET hoặc PUT. POST sẽ trả về 201 đã được tạo để cho biết một tài nguyên mới đã được tạo và DELETE có một vài phản hồi có thể chấp nhận được, cho biết yêu cầu đã được chấp nhận ( 202) hoặc không có nội dung nào để trả về vì tài nguyên không còn tồn tại ( 204).

    Chúng ta có thể kiểm tra code trạng thái của yêu cầu bằng cURL, là công cụ dòng lệnh được sử dụng để truyền dữ liệu thông qua URL. Với curl, theo sau là cờ -i hoặc --incoide, sẽ gửi yêu cầu GET tới một URL và hiển thị header cùng với body. Chúng ta có thể kiểm tra bằng cách mở chương trình dòng lệnh và thử chạy cURL với Google.

    curl -i https://www.google.com

    Server của Google sẽ phản hồi như sau.

    HTTP/2 200 expires: -1 cache-control: private, max-age=0 content-type: text/html; charset=ISO-8859-1 ...

    Như chúng ta có thể thấy, yêu cầu curl trả về nhiều header và toàn bộ body HTML của phản hồi. Vì yêu cầu đã được thực hiện thành công, phần đầu tiên của phản hồi là code trạng thái 200, cùng với phiên bản HTTP (đây sẽ là HTTP/1.1 hoặc HTTP/2).

    Vì yêu cầu cụ thể này trả về một trang web, content-type (loại MIME) được trả về là text/html. Trong RESTful API, bạn thường thấy application/json để cho biết phản hồi là JSON.

    Thật thú vị, chúng ta có thể thấy một kiểu phản hồi khác bằng cách nhập một URL hơi khác. Thực hiện một curl trên Google mà không có www.

    curl -i https://google.com

    HTTP/2 301 location: https://www.google.com/ content-type: text/html; charset=UTF-8

    Google chuyển hướng google.com đến www.google.com và sử dụng code phản hồi 301 để chỉ ra rằng tài nguyên sẽ được chuyển hướng.

    REST API Endpoint

    Khi API được tạo trên một server, dữ liệu mà nó chứa có thể truy cập thông qua các endpoint. Một endpoint là URL của yêu cầu có thể chấp nhận và xử lý yêu cầu GET, POST, PUT hoặc DELETE.

    Một API URL sẽ bao gồm root, path và có thể có chuỗi truy vấn.

    • Root ví dụ như https://api.example.com hoặc https://api.example.com/v2: Gốc của API, có thể bao gồm giao thức, tên miền và phiên bản.
    • Path, ví dụ như, /users/ hoặc /users/5: Vị trí riêng biệt của một tài nguyên cụ thể.
    • Query Parameters (không bắt buộc) ví dụ như, ?location=chicago&age=29: Các cặp giá trị khóa tùy chọn được sử dụng để sắp xếp, lọc và phân trang.

      Chúng ta có thể kết hợp tất cả chúng lại với nhau để cài đặt một thứ gì đó như ví dụ bên dưới, sẽ trả về danh sách tất cả người dùng và sử dụng tham số truy vấn limit để lọc các câu trả lời chỉ bao gồm mười kết quả.

    https://api.example.com/users?limit=10

    Nói chung, khi mọi người nói đến API là RESTful API, họ đang đề cập đến quy ước đặt tên để xây dựng các API URL endpoint. Một vài quy ước quan trọng cho RESTful API tiêu chuẩn như sau:

    • Paths should be plural: ví dụ, để có được người dùng có id là 5, chúng ta sẽ sử dụng /users/5 chứ không phải là /user/5.
    • Endpoint không được hiển thị phần mở rộng tập tin: Mặc dù API thường trả về JSON, nhưng URL không nên kết thúc bằng .json.
    • Endpoint nên sử dụng danh từ, không phải động từ: Các từ như thêmxóa không xuất hiện trong một REST URL. Để thêm một người dùng mới, bạn chỉ cần gửi một yêu cầu POST đến /users, không phải kiểu như /users/add. API nên được phát triển để xử lý nhiều loại yêu cầu cho cùng một URL.
    • Path cần phân biệt chữ hoa chữ thường và nên được viết bằng chữ thường với dấu gạch ngang không phải là dấu gạch dưới.

    Tất cả các quy ước này đều là hướng dẫn, vì không có tiêu chuẩn REST nghiêm ngặt nào cần phải tuân thủ. Tuy nhiên, sử dụng các nguyên tắc này sẽ giúp API của bạn nhất quán, quen thuộc và dễ đọc cũng như dễ hiểu.

    Tổng kết

    Trong bài viết này, chúng ta đã tìm hiểu về REST và RESTful API là gì, các phương thức yêu cầu HTTP và code phản hồi hoạt động như thế nào, cấu trúc của một API URL và các quy ước RESTful API phổ biến. Trong hướng dẫn tiếp theo, chúng ta sẽ tìm hiểu cách sử dụng tất cả lý thuyết này để thiết lập một server Expss với chúng tôi và xây dựng API của riêng chúng ta.

    --- Bài cũ hơn ---

  • Restful Api Cho Người Bắt Đầu
  • Bài 1: Cách Tạo Ứng Dụng Web Api
  • Cách Viết Và Cấu Trúc Chi Tiết Một Bài Báo Khoa Học
  • Để Viết “phần Tóm Tắt” Của Một Bài Báo Nghiên Cứu Khoa Học Bằng Tiếng Anh
  • Hướng Dẫn Viết Argumentative Essay
  • Cách Tạo Api Với Rails (Phần 2) Viết Test Case

    --- Bài mới hơn ---

  • Học Kiểm Thử Api Trong 10 Phút
  • Giới Thiệu Tool Swagger Ui
  • Cách Viết Rails Api Document
  • Tôi Đã Viết Api Document Cho Dự Án Như Thế Nào?
  • Viết Api Document Cho Dự Án Sử Dụng Laravel
  • Tiếp theo Cách tạo API với Rails (phần 1)

    Mình sẽ hướng dẫn cách test căn bản cho API mình tạo. Thật ra mà nói thì mình phải viết test trước khi làm nhưng mà để tránh việc gây khó hiểu nên mình xin mạn phép đảo ngược qui trình.

    Để thuận lợi hơn cho việc viết test case mình sử dụng gem rspec-rails

    Test case thuộc tính của model mình đã tạo

    Để dễ dàng hơn trong việc viết test case mình sử dụng thêm 2 gem:

    • Gem factory_girl_rails để tạo fixture data
    • Gem shoulda
    • Nhớ bundle install lại sau khi add gem

    Chúng ta tạo lại model traveler

    rails g model traveler first_name:string last_name:string birthday:datetime gender:string

    Bây giờ cấu trúc app của chúng ta sẽ xuất hiện thêm phần này ( màu xanh lá cây)

    Tạo fixture data

    Vào file sau spec/factories/travelers.rb để kiểm tra lại fixture data mà FactoryGirls đã tạo. Mình sẽ edit lại một tí ( dựa vào gem ffake )

    FactoryGirl.define do factory :traveler do first_name { FFaker::Name.first_name } last_name { FFaker::Name.last_name } birthday { FFaker::IdentificationESCO.expedition_date } gender { FFaker::Gender.maybe } end end

    Test các thuộc tính của model

    Bạn tạo model cho traveler và test cho traveler nên bạn sẽ viết test case tại file traveler_spec.rb

    Vào file sau spec/models/traver_spec.rb để viết test case

    require 'rails_helper' describe Traveler do before { @traveler = FactoryGirl.build(:traveler) } subject { @traveler } it { should respond_to(:first_name) } it { should respond_to(:last_name) } it { should respond_to(:gender) } it { should respond_to(:birthday) } end

    Kiểm tra kết quả của test case

    Tại terminal bạn gõ theo cấu trúc rspec **đường đẫn file muốn test**

    rspec spec/models/traveler_spec.rb

    Test respond trả về khi request api

    • Test response code trả về thành công là 200
    • Test data trả về gồm những thành phần gì

    require 'spec_helper' describe V1::TravelersController do before do @traveler = FactoryGirl.create :traveler get "/v1/travelers", format: :json end it 'return traveler information' do traveler = JSON.parse(response.body, symbolize_names: true).first expect(traveler).to eql @traveler.last_name expect(traveler.to_s.to_i).to eql @traveler.birthday.to_s.to_i end it 'response code' do expect(response).to have_http_status(200) end end

    Run lệnh này để kiểm tra kết quả

    rspec spec/requests/v1/travelers_controller_spec.rb

    Yah! đã xong

    --- Bài cũ hơn ---

  • How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)
  • Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu
  • Cách Test Api Như Thế Nào?
  • Hướng Dẫn Tạo Secure Rest Api Trong
  • Sử Dụng WordPress Rest Api Toàn Tập
  • 13 Mẹo Để Viết Testcase Cho Bất Kỳ Ứng Dụng Nào

    --- Bài mới hơn ---

  • Viết Test Case Cho Phần Đăng Nhập Của Một App Mobile
  • Mẫu Test Cases Để Kiểm Tra Web Và Ứng Dụng Desktop
  • Bài 4. Kiểm Thử Ứng Dụng Di Động
  • Checklist Cho Kiểm Thử Ứng Dụng Di Động
  • 5 Cách Viết Ứng Dụng Di Động
  • Test cases rất quan trọng đối với bất kỳ dự án nào vì đây là bước đầu tiên trong bất kỳ chu kỳ thử nghiệm nào và nếu có bất cứ sai sót trong bước này, các tác động sẽ bị rất lớn khi bạn đi tiếp trong chu kỳ kiểm thử phần mềm.

    Biết làm thế nào để viết các trường hợp kiểm thử tốt là điều cực kỳ quan trọng đối với chúng ta, nó là một nguồn lực thử nghiệm.

    Viết Test cases là một hoạt động có ảnh hưởng lớn đến giai đoạn thử nghiệm và điều này làm cho các trường hợp thử nghiệm trở thành một phần quan trọng trong quá trình thực hiện thử nghiệm!

    Vì vậy, việc viết các testcase có hiệu quả cũng như tái sử dụng là rất quan trọng; các trường hợp thử nghiệm tốt sẽ tiết kiệm rất nhiều thời gian trong các giai đoạn thử nghiệm sau (thực sự) nếu bạn thực hiện đúng trong lần thử đầu tiên …

    A. Thế nào là testcase?

    Một Testcase chỉ đơn giản là một danh sách các hành động cần phải được thực hiện để xác minh một chức năng cụ thể hoặc tính năng của ứng dụng đang được kiểm tra.

    B. LỜI KHUYÊN ĐƠN GIẢN ĐỂ VIẾT TESTCASE HIỆU QUẢ

    Viết Testcase hiệu quả là một kỹ năng và bạn chỉ có thể đạt được nó thông qua việc thực hành và sự hiểu biết sâu sắc về ứng dụng để áp dụng cho trường hợp thử nghiệm đang được viết. Kết hợp một số mẹo đơn giản mà tôi sẽ đưa ra ở đây sẽ giúp bạn nắm vững được kỹ năng viết testcase tốt.

    1. Quy ước đặt tên Testcase

    Mặc dù đây là mẹo đơn giản nhất trong danh sách này, nhưng đa số chúng ta thực hiện nó chưa hiệu quả.

    Chúng ta nên nhớ: Luôn đặt tên một cách có ý nghĩa nhất, dễ hiểu đối với bất kỳ ai sẽ thực hiện các trường hợp thử nghiệm trong tương lai (bao gồm BẠN!).

    Mẹo nhanh: Đặt tên cho các testcase để mô tả tên mô-đun hoặc khu chức năng mà bạn sẽ xác minh trong trường hợp kiểm tra đó.

    Ví dụ: Có hệ thống bán hàng online, trong đó có chức năng: Đăng Ký Vậy, khi viết testcase, thay cho việc viết tên TC_01, ta sẽ viết cụ thể thêm chức năng đang nói tới: TC_Đăng_Ký

    2. Mô tả cho Testcase

    Mô tả là nơi bạn đề cập đến tất cả các chi tiết về những gì sẽ kiểm tra, và hành vi đặc biệt được xác minh bằng kịch bản kiểm tra.

    Các “mô tả” của một trường hợp thử nghiệm nên xác định “Tôi sẽ kiểm tra những gì? Kiểm tra như thế nào? (Những gì cần phải được xác minh, môi trường thử nghiệm nó cần được xác minh trong đó dữ liệu thử nghiệm được sử dụng – tất cả các thông tin này được cụ thể ở phần mô tả.)

    Mẹo nhanh: Đưa càng nhiều thông tin càng tốt trong phần mô tả của testcase!

    3. Giả định và điều kiện tiên quyết

    Trong khi viết các testcase, bạn nên truyền đạt tất cả các giả định áp dụng cho bài kiểm tra, cùng với các điều kiện tiên quyết cần phải đáp ứng trước khi kiểm tra có thể được thực hiện.

    • Bất kỳ phụ thuộc dữ liệu người dùng nào (ví dụ: người dùng phải đăng nhập, trang nào người dùng bắt đầu cuộc hành trình, v.v …)
    • Sự phụ thuộc vào môi trường thử nghiệm
    • Bất kỳ thiết lập đặc biệt nào được thực hiện trước khi thực thi thử nghiệm
    • Sự phụ thuộc vào bất kỳ trường hợp kiểm tra nào khác – Trường hợp thử nghiệm cần được thực hiện trước / sau một số trường hợp kiểm tra khác không?

    Mẹo nhanh: Đảm bảo thêm càng nhiều thông tin càng tốt để có thể đáp ứng các điều kiện trước khi chạy thử.

    4. Dữ liệu truyền vào

    Xác định dữ liệu thử nghiệm có thể rất tốn thời gian – bởi vì cần nhiều lần chuẩn bị dữ liệu thử nghiệm, nên mất nhiều thời gian trong một chu kỳ thử nghiệm.

    Đôi khi bạn cần tạo một dữ liệu thử nghiệm một lần nữa vì việc tạo ra một dữ liệu mới có thể mất ít thời gian hơn so với việc xác định nó

    Để dễ dàng cho một người thử nghiệm (và những người kiểm thử khác), Bất cứ khi nào có thể, bạn có thể cung cấp cho họ dữ liệu thử nghiệm để sử dụng cho các trường hợp thử nghiệm trong mô tả của testcase hoặc với từng bước cụ thể trong testcase Điều này sẽ tiết kiệm rất nhiều thời gian trong quá trình bạn cần phải thực hiện lại các testcase

    Một vài gợi ý:

    • Trong nhiều trường hợp bạn biết dữ liệu thử nghiệm có thể được sử dụng lại theo thời gian, bạn có thể đề cập đến chính xác dữ liệu kiểm tra để sử dụng cho việci kiểm thử.
    • Nếu thử nghiệm chỉ bao gồm một số giá trị được xác minh, bạn có thể chọn để chỉ định phạm vi giá trị hoặc mô tả những giá trị nào sẽ được kiểm tra cho trường nào.
    • Kiểm tra với mỗi giá trị là không thực tế, do đó bạn có thể chọn một vài giá trị từ mỗi lớp tương đương mà nên cung cấp cho bảo hiểm tốt cho bài kiểm tra của bạn.
    • Bạn cũng có thể quyết định đề cập đến loại dữ liệu được yêu cầu để chạy thử nghiệm chứ không phải giá trị dữ liệu thử nghiệm thật sự. Điều này áp dụng cho các dự án mà dữ liệu thử nghiệm vẫn tiếp tục thay đổi khi nhiều nhóm sử dụng nó và có thể không ở trong cùng một trạng thái khi sử dụng nó trong lần tiếp theo

    5. Xác nhận bao gồm tất cả các bước Thiết kế thử nghiệm

    Một phần quan trọng khác của một trường hợp thử nghiệm tốt, là các bước xác minh trường hợp thử nghiệm được xác định chính xác bao gồm tất cả các điểm xác minh đối với tính năng được thử.

    Mẹo nhanh: Các bước Thiết kế Thử nghiệm không chỉ bao gồm các luồng chức năng mà còn phải đảm bảo mỗi điểm được kiểm tra!

    Bằng cách so sánh các bước Test Case của bạn với các tài liệu (Tài liệu yêu cầu, trường hợp sử dụng, bản đồ quy trình) dự án của bạn, bạn có thể đảm bảo rằng Test Case tối ưu bao gồm tất cả các điểm xác minh.

    Nếu sự thay đổi bạn đang thử nghiệm không lớn, bạn có thể cân nhắc đề cập đến nó trong bước kiểm tra.

    7. Kết quả mong đợi

    Một testcase rõ ràng sẽ đề cập rõ kết quả dự kiến của ứng dụng hoặc hệ thống đang thử nghiệm. Mỗi bước thiết kế thử nghiệm cần đề cập rõ ràng những gì bạn mong đợi như là kết quả của bước xác minh đó.

    Vì vậy, trong khi viết các trường hợp thử nghiệm, hãy đề cập chi tiết về trang / màn hình mà bạn mong đợi xuất hiện sau bài kiểm tra, và bất kỳ bản cập nhật nào bạn mong đợi như là một kết quả sẽ được thực hiện trong hệ thống hoặc cơ sở dữ liệu back-end (ví dụ như một mục nhập mới nên ghi vào Bảng dữ liệu).

    Bạn cũng có thể đính kèm ảnh chụp màn hình hoặc tài liệu đặc tả cho bước tương ứng đề cập đến hệ thống nên hoạt động như đã nêu trong tài liệu cho trước để làm cho mọi thứ đơn giản hơn.

    8. Phân chia các trường hợp kiểm tra chức năng đặc biệt thành các bộ

    Để viết bài kiểm tra hiệu quả, bạn nên xem xét việc phân chia các testcase thành các bộ và các bộ phụ để kiểm tra một số tình huống đặc biệt như các hành vi cụ thể của trình duyệt, xác minh cookie, kiểm tra khả năng sử dụng, kiểm tra dịch vụ Web và kiểm tra các điều kiện lỗi …

    Mẹo nhanh: Nếu trong khi viết các kịch bản này thành tập hợp, một tính năng cụ thể có nhiều kết hợp đầu vào, bạn có thể tách thử nghiệm thành các testcase phụ

    9. Dễ đọc và dễ hiểu

    Dù dự án bạn làm việc, khi thiết kế các trường hợp thử nghiệm, bạn nên luôn luôn xem xét rằng Các trường hợp kiểm tra sẽ không phải luôn luôn được thực hiện bởi người thiết kế chúng. Vì vậy, các bài kiểm tra phải dễ hiểu, dễ đọc và chính xác.

    Bộ phần mềm thử nghiệm chỉ có thể hiểu được bởi những người thiết kế chúng là phổ biến. Vì vậy, bạn nên tập trung vào việc viết các testcase mà:

    • Đều đơn giản và dễ hiểu bởi tất cả mọi người (kể cả BẠN!)
    • Chia nhỏ các thử nghiệm một cách tối giản thành một Thử nghiệm mới vẫn có đủ độ phủ sóng

    10. Kiểm tra lại

    Các testcase đóng một vai trò quan trọng trong vòng đời Kiểm thử Phần mềm. Hãy đảm bảo rằng chúng là chính xác và phù hợp với các tiêu chuẩn, thậm chí còn rất cần thiết

    11. Có thể tái sử dụng

    Bạn nên viết các test case với suy nghĩ rằng chúng có thể được tái sử dụng trong tương lai đối với các nhóm hoặc dự án khác.

    • Chú ý rằng, trước khi viết một Test case mới cho dự án hay module của bạn, luôn luôn cố gắng tìm ra nếu các test case đã được viết sẵn đối với vùng giống nhau? Điều đó thực sự giúp tiết kiệm được nhiều thời gian.
    • Nếu bạn dành chút thời gian với các nhóm khác để tìm ra các test case đã có sẵn thì bạn có thể may mắn là sẽ không lặp lại một số test case, từ đó tránh được sự dư thừa trong các công cụ quản lý test (như ALM hoặc QC).
    • Ngoài ra, nếu bạn có được các test case đã được viết sớm hơn xung quanh module giống nhau, bạn sẽ phải cập nhật chúng thay vì viết các test case mới. Do đó, với bất kỳ tiến trình nào cũng luôn có các test case được cập nhật ở mọi nơi. Điều này có thể không được áp dụng nếu dự án của bạn là một dự án mới, tuy nhiên, bạn có thể cố gắng viết các test case mới bằng cách mà chúng có thể được tái sử dụng đối với một vài dự án khác trong tương lai. Ngoài ra, nếu bạn cần một test case cụ thể để thực hiện một số test case khác, bạn có thể gọi đơn giản test case đã tồn tại trong tiền điều kiện (p-condition) hoặc tại một bước của test design.

    12. Bảo trì & Cập nhật

    • Nó rất quan trọng để đảm bảo rằng các Test case luôn được cập nhật theo những thay đổi đã được đề cập ở hiện tại trong ứng dụng mà họ áp dụng.

    • Việc nhắc lại điểm của tôi về khả năng sử dụng lại, trong trường hợp có thay đổi đối với tiến trình hoặc chức năng hiện tại, bạn PHẢI xem xét cập nhật các Test case hiện tại thay vì viết thêm bất kỳ Test case mới nào, từ đó tránh sự dư thừa đối với bộ test case hiện tại.

    • Điều này cũng đảm bảo bạn luôn cập nhật các Test case cho bất kỳ tiến trình nào trong ứng dụng của bạn.

    13. Các điều kiện công bố

    All Rights Reserved

    --- Bài cũ hơn ---

  • Mobile Apps Testing: Mẫu Test Case & Kịch Bản Kiểm Thử
  • Cách Viết Test Case Cho Phần Mềm
  • Lập Trình Ứng Dụng Facebook
  • Cách Tạo Một Facebook Apps Và Lấy App Id, Secret Key
  • Cách Tải Ứng Dụng Trên App Store Cho Iphone
  • Laravel: Hướng Dẫn Laravel Api: Cách Xây Dựng Và Kiểm Tra Một Restful Api

    --- Bài mới hơn ---

  • Restful Api Là Gì? Xây Dựng Webservice Với Restful Api Trong Php
  • Hướng Dẫn Tuyệt Vời Về Cách Xây Dựng Api Restful Vớicore
  • Làm Quen Với Web Api 2 Trong .net
  • Api Là Gì Trong Java
  • Hướng Dẫn Lập Trình Java Restful Web Service Cho Người Mới Bắt Đầu
  • Với sự phát triển của khung phát triển di động và JavaScript, sử dụng API RESTful là tùy chọn tốt nhất để xây dựng một giao diện duy nhất giữa dữ liệu của bạn và máy khách của bạn.

    Trong hướng dẫn này, chúng ta sẽ khám phá những cách bạn có thể xây dựng và thử nghiệm API mạnh mẽ bằng cách sử dụng Laravel với xác thực. Chúng ta sẽ sử dụng Laravel 5.x.

    API RESTful

    Trước tiên, chúng ta cần hiểu chính xác những gì được coi là API RESTful. REST là viết tắt của REpsentational State Transfer và là một kiểu kiến ​​trúc để giao tiếp mạng giữa các ứng dụng, dựa trên giao thức không trạng thái (thường là HTTP) để tương tác.

    Động từ HTTP đại diện cho hành động

    Trong API RESTful, chúng ta sử dụng các động từ HTTP làm hành động và các điểm cuối là tài nguyên được tác động. Chúng ta sẽ sử dụng các động từ HTTP cho ý nghĩa ngữ nghĩa của chúng:

    • GET: lấy tài nguyên
    • POST: tạo tài nguyên
    • PUT: cập nhật tài nguyên
    • DELETE: xóa tài nguyên

    Cập nhật hành động: PUT so với POST

    API RESTful là một vấn đề của nhiều cuộc tranh luận và có rất nhiều ý kiến trên mạng về việc là tốt nhất để cập nhật với POST, PATCH hay PUT, hoặc nếu hành động tạo ra là tốt nhất còn lại để các PUT động từ. Trong bài viết này, chúng tôi sẽ sử dụng PUT cho hành động cập nhật, theo HTTP RFC, PUT có nghĩa là tạo/cập nhật tài nguyên tại một vị trí cụ thể. Một yêu cầu khác cho động từ PUT là idempotence, trong trường hợp này về cơ bản có nghĩa là bạn có thể gửi yêu cầu đó 1, 2 hoặc 1000 lần và kết quả sẽ giống nhau: một tài nguyên được cập nhật trong cơ sở dữ liệu.

    Tài nguyên

    Tài nguyên sẽ là mục tiêu của các hành động, trong trường hợp của chúng tôi là Bài viết và Người dùng và chúng có điểm cuối riêng:

    Trong hướng dẫn api laravel này, các tài nguyên sẽ có tỷ lệ 1:1 trên các mô hình dữ liệu của chúng ta, nhưng đó không phải là một yêu cầu. Bạn có thể có các tài nguyên được thể hiện trong nhiều hơn một mô hình dữ liệu (hoặc hoàn toàn không được đại diện trong cơ sở dữ liệu) và các mô hình hoàn toàn vượt quá giới hạn cho người dùng. Cuối cùng, bạn có thể quyết định cách kiến ​​trúc sư tài nguyên và mô hình theo cách phù hợp với ứng dụng của bạn.

    Lưu ý về tính nhất quán

    Ưu điểm lớn nhất của việc sử dụng một tập hợp các quy ước như REST là API của bạn sẽ dễ dàng tiêu thụ và phát triển hơn nhiều. Một số điểm cuối khá đơn giản và do đó, API của bạn sẽ dễ sử dụng và bảo trì hơn nhiều so với việc có các điểm cuối như GET /get_article?id_article=12POST /delete_article?number=40. Tôi đã xây dựng các API khủng khiếp như thế trong quá khứ và tôi vẫn ghét bản thân mình vì nó.

    Tuy nhiên, sẽ có những trường hợp khó có thể ánh xạ tới lược đồ Create/Retrieve/Update/Delete. Hãy nhớ rằng các URL không được chứa động từ và tài nguyên không nhất thiết phải là hàng trong một bảng. Một lưu ý khác là bạn không phải thực hiện mọi hành động cho mọi tài nguyên.

    Thiết lập dự án web service của Laravel

    Như với tất cả các framework PHP hiện đại, chúng tôi sẽ cần Composer để cài đặt và xử lý các phụ thuộc của chúng tôi. Sau khi bạn làm theo các hướng dẫn tải xuống (và thêm vào biến môi trường đường dẫn của bạn), hãy cài đặt Laravel bằng lệnh:

    $ composer global require laravel/installer

    Sau khi cài đặt kết thúc, bạn có thể tạo ra một ứng dụng mới như thế này:

    Đối với lệnh trên, bạn cần phải có ~/composer/vendor/bin trong $PATH. Nếu bạn không muốn giải quyết vấn đề đó, bạn cũng có thể tạo một dự án mới bằng Composer:

    $ composer create-project --pfer-dist laravel/laravel myapp

    Với cài đặt Laravel, bạn sẽ có thể khởi động máy chủ và kiểm tra xem mọi thứ có hoạt động không:

    Di chuyển và mô hình

    Trước khi thực sự viết di chuyển đầu tiên của bạn, hãy đảm bảo bạn đã tạo cơ sở dữ liệu cho ứng dụng này và thêm thông tin đăng nhập vào .env tệp nằm trong thư mục gốc của dự án.

    DB_CONNECTION=mysql

    DB_HOST=127.0.0.1

    DB_PORT=3306

    DB_DATABASE=homestead

    DB_USERNAME=homestead

    DB_PASSWORD=secret

    Bạn cũng có thể sử dụng Homestead, một hộp Vagrant được chế tạo đặc biệt cho Laravel, nhưng đó là một chút ngoài phạm vi của bài viết này.

    Hãy bắt đầu với mô hình đầu tiên của chúng ta và di chuyển Điều khoản. Bài viết nên có một tiêu đề và một lĩnh vực cơ thể, cũng như một ngày sáng tạo. Laravel cung cấp một số lệnh thông qua công cụ dòng lệnh Artisan của Laravel giúp chúng ta bằng cách tạo các tệp và đặt chúng vào các thư mục chính xác. Để tạo mô hình Bài viết, chúng ta có thể chạy:

    $ php artisan make:model Article -m

    Tùy chọn -m là chữ viết tắt --migration và nó nói với Artisan để tạo ra một mô hình của chúng tôi. Đây là di chuyển được tạo:

    Chúng ta hãy mổ xẻ điều này trong một giây:

    • Các phương thức up()down() sẽ được chạy khi chúng ta di chuyển và khôi phục tương ứng;
    • Và cuối cùng, Schema::dropIfExists() tất nhiên, sẽ bỏ bảng nếu nó tồn tại.

    Ngoài ra, hãy thêm hai dòng vào up() phương thức của chúng tôi :

    Bạn cũng có thể sử dụng tùy chọn --step ở đây và nó sẽ tách từng di chuyển thành lô riêng để bạn có thể cuộn chúng lại nếu cần.

    Bây giờ, hãy quay lại mô hình của chúng tôi và thêm các thuộc tính đó vào $fillable trường để chúng tôi có thể sử dụng chúng trong mô hình Article::createArticle::update mô hình của chúng tôi:

    class Article extends Model { protected $fillable = '); Route::get('articles/{id}', 'articles','); Route::put('articles/{id}',');

    Chúng tôi có thể cải thiện các điểm cuối bằng cách sử dụng ràng buộc mô hình tuyến đường ngầm. Bằng cách này, Laravel sẽ đưa Article cá thể vào các phương thức của chúng tôi và tự động trả về 404 nếu không tìm thấy. Chúng tôi sẽ phải thay đổi tệp tuyến đường và trên bộ điều khiển:

    Route::get('articles', ''ArticleControl''''); Route::post('articles/{article}','); Route::delete();

    Trong phần trên, chúng tôi đã sử dụng một phương thức trên mô hình Người dùng để tạo mã thông báo. Điều này hữu ích để chúng tôi chỉ có một cách duy nhất để tạo mã thông báo. Thêm phương thức sau vào mô hình Người dùng của bạn:

    Và đó là nó. Người dùng hiện đang đăng ký và nhờ xác nhận Laravel và ra khỏi xác thực hộp, name, email, password, và password_confirmationlĩnh vực được yêu cầu, và các thông tin phản hồi được xử lý tự động. Kiểm tra validator()phương thức bên trong RegisterController để xem các quy tắc được thực hiện như thế nào.

    Đây là những gì chúng ta nhận được khi đạt điểm cuối đó:

    $ curl -X POST http://localhost:8000/api/register -H "Accept: application/json" -H "Content-Type: application/json" -d '{"name": "John", "email": "", "id": 51, "name": "John", "updated_at": "2017-06-20 21:17:15" } }

    Tạo một điểm cuối đăng nhập

    Và chúng ta có thể liên kết nó trên tập tin tuyến đường:

    Route::post('login', 'Auth", "password": "toptal" }"

    Để gửi mã thông báo trong yêu cầu, bạn có thể thực hiện bằng cách gửi một thuộc tính api_tokentrong tải trọng hoặc dưới dạng mã thông báo mang trong tiêu đề yêu cầu ở dạng Authorization: Bearer Jll7q0BSijLOrzaOSm5Dr5hW9cJRZAJKOzvDlxjKCXepwAeZ7JR6YP5zQqnw.

    Đăng xuất

    Với chiến lược hiện tại của chúng tôi, nếu mã thông báo bị sai hoặc bị thiếu, người dùng sẽ nhận được phản hồi không được xác thực (chúng tôi sẽ triển khai trong phần tiếp theo). Vì vậy, đối với điểm cuối đăng xuất đơn giản, chúng tôi sẽ gửi mã thông báo và nó sẽ bị xóa trên cơ sở dữ liệu.

    routes/api.php:

    Route::post('logout', 'Auth, ... },

    Lệnh kiểm tra sẽ có sẵn như thế này:

    $ composer test

    Thiết lập các nhà máy cho các thử nghiệm của chúng tôi

    Các nhà máy sẽ cho phép chúng tôi nhanh chóng tạo các đối tượng với dữ liệu phù hợp để thử nghiệm. Chúng nằm trong database/factoriesthư mục. Laravel ra khỏi hộp với một nhà máy cho Userlớp, vì vậy hãy thêm một cái cho Article lớp:

    Các Faker thư viện đã được tiêm để giúp chúng tôi tạo ra định dạng đúng của dữ liệu ngẫu nhiên cho các mô hình của chúng tôi.

    Thử nghiệm đầu tiên của chúng tôi

    Chúng ta có thể sử dụng các phương thức khẳng định của Laravel để dễ dàng đạt điểm cuối và đánh giá phản ứng của nó. Hãy tạo thử nghiệm đầu tiên của chúng tôi, thử nghiệm đăng nhập, sử dụng lệnh sau:

    $ php artisan make:test Feature/LoginTest

    Và đây là bài kiểm tra của chúng tôi:

    Những phương pháp này kiểm tra một vài trường hợp đơn giản. Các json()phương pháp chạm endpoint và người kia khẳng định là khá tự giải thích. Một chi tiết về assertJson(): phương thức này chuyển đổi phản hồi thành một mảng tìm kiếm đối số, vì vậy thứ tự là quan trọng. Bạn có thể xâu chuỗi nhiều assertJson() cuộc gọi trong trường hợp đó.

    Bây giờ, hãy tạo bài kiểm tra điểm cuối đăng ký và viết một cặp cho điểm cuối đó:

    $ php artisan make:test RegisterTest

    Và cuối cùng, điểm cuối đăng xuất:

    $ php artisan make:test LogoutTest

    Điều quan trọng cần lưu ý là, trong quá trình thử nghiệm, ứng dụng Laravel không được khởi tạo lại theo yêu cầu mới. Điều đó có nghĩa là khi chúng ta nhấn phần mềm trung gian xác thực, nó sẽ lưu người dùng hiện tại bên trong TokenGuard thể hiện để tránh đánh lại cơ sở dữ liệu. Một lựa chọn khôn ngoan, tuy nhiên, trong trường hợp này, điều đó có nghĩa là chúng ta phải chia bài kiểm tra đăng xuất thành hai, để tránh mọi vấn đề với người dùng được lưu trong bộ nhớ cache trước đó.

    Việc kiểm tra các điểm cuối của Điều cũng rất đơn giản:

    Bước tiếp theo

    Thats tất cả để có nó. Chắc chắn có cơ hội để cải thiện, bạn có thể triển khai OAuth2 với gói Passport , tích hợp lớp chuyển đổi và phân trang (tôi khuyên dùng Fractal), danh sách này có trên nhưng tôi muốn tìm hiểu những điều cơ bản về tạo và thử nghiệm API trong Laravel mà không cần gói bên ngoài.

    Laravel chắc chắn đã cải thiện trải nghiệm của tôi với PHP và việc dễ dàng thử nghiệm với nó đã củng cố mối quan tâm của tôi đối với khung công tác. Nó không hoàn hảo, nhưng nó đủ linh hoạt để cho phép bạn giải quyết các vấn đề của nó.

    Nếu bạn đang thiết kế API công khai, hãy xem 5 Quy tắc vàng cho Thiết kế API web tuyệt vời .

    --- Bài cũ hơn ---

  • Xây Dựng Webservice Với Restful Api Trong Php
  • Hướng Dẫn Viết Luận Văn
  • Dịch Vụ Viết Luận Văn Tiếng Anh
  • Bài Báo Khoa Học P6: Viết Tóm Tắt Abstract
  • Tham Khảo Các Bài Mẫu Argumentative Essay Hay Nhất
  • Web hay
  • Links hay
  • Push
  • Chủ đề top 10
  • Chủ đề top 20
  • Chủ đề top 30
  • Chủ đề top 40
  • Chủ đề top 50
  • Chủ đề top 60
  • Chủ đề top 70
  • Chủ đề top 80
  • Chủ đề top 90
  • Chủ đề top 100
  • Bài viết top 10
  • Bài viết top 20
  • Bài viết top 30
  • Bài viết top 40
  • Bài viết top 50
  • Bài viết top 60
  • Bài viết top 70
  • Bài viết top 80
  • Bài viết top 90
  • Bài viết top 100