hf5xaghzz3.apidog.io Open in urlscan Pro
18.209.226.156  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Sorry, we need js to run correctly!
CHRIS

 * 🐶 Walk through Apidog
 * Mobile
 * CMS
   * Auth
     * LoginPOST
     * Refresh TokenPOST
     * Change PasswordPUT
     * Reset PasswordPUT
   * User
     * Get All UserGET
     * Get User By IDGET
     * Delete UserDELETE
     * Update UserPATCH
     * Get Dashboard StatusGET
   * Admin
     * DashboardGET
     * RegisterPOST
   * Daily Attendance
     * Get DailyAttendanceGET
     * Get Users AttendanceGET
     * Checkin Daily AttendancePOST
     * Checkout Daily AttendancePUT
     * Approval AttendancePUT
   * Model
   * Daily Standup
   * Roles
   * Project Product
   * Leave Type
   * Leave Permit
   * Test Protected RouteGET

Powered by Apidog



🐶 WALK THROUGH APIDOG


> 📄 CONTENTS#
> 
>  * What is Apidog
>  * Why Apidog
>  * API Designers: Specify APls
>  * Back-end Developers: API Developing & Debugging
>  * Front-end Developers: API Mocking
>  * QA Engineers: APl Testing
>  * API Designers & API Consumers: APl Documentations
>  * Best Practice


WHAT IS APIDOG#

Apidog is an all-in-one toolkit for API development. The whole team can work on
it together to produce APIs efficiently and conveniently. Each role in the team
can use it to solve their own problems.



Apidog follows the API-first approach, which is a development approach where the
API is designed and developed before the user interface. This approach has
several benefits, such as:

 1. Apidog allows teams to work in parallel and establish a contract between
    services, allowing them to work on multiple APIs simultaneously and
    improving development speed.
 2. Automation can be achieved by using tools that import API definition files,
    reducing the time needed to develop and launch an API.
 3. It ensures a good developer experience, with well-designed and
    well-documented APIs, making it easy for developers to use and reuse code,
    onboard new developers, and reduce the learning curve.
 4. By solving most of the problems before any code is written, it can also
    prevent issues when integrating APIs with applications.

Apidog can help you achieve all these benefits above.


WHY APIDOG#

We have observed that development teams often utilize a variety of tools, such
as Postman, Swagger, Stoplight, and Jmeter, to design, manage, and test APIs
during the development process. However, the absence of data synchronization and
collaboration between these tools can significantly hinder efficiency.

A better solution is for the entire development team to work within a single API
tool. As long as the API documentation is defined, back-end developers can
easily implement and self-test the API, front-end developers can easily call the
API and use mock data, and test engineers can directly test the API and easily
generate test cases. This greatly improves the efficiency of team collaboration.

That is why we created the Apidog product. It is a comprehensive tool for API
design, development, testing, management, documentation, and mocking,
specifically designed for team collaboration.


API DESIGNERS: SPECIFY APIS#

API designers can use Apidog to specify APIs visually or import from OpenAPI
specifications.


IMPORT FROM OPENAPI SPECIFICATIONS#

If your API has been specified in OpenAPI or any other format, you can import it
into Apidog so that it can be easily debugged, tested, or mocked.

 1. Click Import in an Apidog project.



 2. Switch to URL Import, paste the following URL and click Submit.

https://petstore.swagger.io/v2/swagger.json




You can also select a JSON or YAML file to import. Other API specifications
formats are also supported, such as Apidog, HAR, etc.

 3. Click Confirm to import.



 4. Now you can run or test the API in Apidog.



TIP

Learn more about importing data here.


SPECIFY A NEW API#

API designers can use Apidog to specify APIs in an intuitive interface.

 1. Start a new tab and click New API to create an endpoint.



 2. Now we're going to specify an API for querying user information by id. So
    you can enter these fields into the API.
    * API Path
      * /users/{id}
    * Name
      * Get user by id



 3. This API has no query params or body params. You'll see 'id' recognized as a
    path param. Now the Request part is finished.
 4. Roll to the Responses part. In the 'OK(200)' response, change the field type
    of the root node to 'Refs Model - Schemas - ApiResponse'.



 5. Now this API has a general JSON structure like the following. Each API has a
    different 'data' field, so add a child node to the root node and name it
    'data'.



 6. Change the field type of the 'data' node to 'Refs Model' - 'Schemas' -
    'User'.



 7. Now the response structure is specified well. If you need to edit the 'data'
    structure, you can dereference the schema or dereference a field to edit.



TIP

Learn more about Data Schema here.

 8. Roll to the Response Examples part. Click Add Example.



 9. Name the example 'Success'. Now it's the magical part: click Generate
    Automatically, and the response data will be generated according to the
    response structure. Click OK to add the example.



 10. Click Save to finish the API specification. You'll get a well-designed API.




BACK-END DEVELOPERS: API DEVELOPING & DEBUGGING#

Different teams adopt different development approaches. Some teams adopt
API-first, and some teams adopt code-first. Regardless of which method your team
uses, back-end developers can use Apidog to assist in the development and
debugging of the API.


GENERATE CODE#

 1. While APIs are specified, server stubs and client SDKs can be generated
    easily. Just click Generate Code on the API page and select Generate Server
    Stubs & Client SDKs.



 2. Using the OpenAPI Generator engine, server stubs and client SDKs in tens of
    languages can be generated.



TIP

Learn more about Code Generation here.


RUN THE API#

After API development is completed, the back-end often needs to debug whether
the API can give the correct output under different input parameters. Using
Apidog makes it easy to debug each API and ensure that they are running
normally.

 1. In the API page we just created, click the Run button to enter the Run tab.



 2. Enter '1' to the 'id' param. In the request URL to be sent, {id} will be
    replaced by the value '1'.



 3. Click the Manage Environments button at the top right.



 4. Switch to 'Test Env', and paste the following URL into the 'Default Server'
    service. Then save the environment.

https://mock.apidog.com/m1/352945-0-default


TIP

Learn more about Environment Management here.



 5. Select the 'Testing Env' so that all the requests will be sent with the base
    URL just configured in the front.



 6. Click Send to send the request. The response of the API will be displayed
    below.




DEBUGGING#

After the API is developed, the back-end needs to test whether it can return the
expected data and whether the API has implemented the correct business logic.

 1. Set the value of the path param to '2', and Send the request.



 2. You'll see an alert '🚫Response data differs from API specification:
    .data.idshouldbeinteger′.Thatisbecausethe.data.id should be integer'. That
    is because the .data.idshouldbeinteger′.Thatisbecausethe.data.id is
    specified as an integer, but the $.data.id in the actual response is a
    string.



 3. Apidog automatically verifies whether the API definition and actual response
    are consistent. Issues such as incorrect data types, undefined enumerated
    values, missing required fields, and so on will be automatically detected.
    The back-end can easily discover problems in the response data.
 4. Click Save APICase to save the request. The requests will be saved as
    children of the API and can be referenced in the testing module.






USE VARIABLES#

In Apidog, variables are used to store values that can be reused across
requests.

Environment variables are specific to an environment, meaning that they are only
accessible when a particular environment is selected. Global variables, on the
other hand, are accessible across all environments.

You can define environment variables in the "Manage Environments" section of
Apidog, and reference them in your requests using double curly braces notation,
for example {{variableName}}.

Here is an example.

 1. Fill the path param 'id' with {{Userid}}.



 2. Click Environment Management. Add a new variable named Userid, and fill the
    Current Value with '1'. Save the Variable.



 3. Send the request. Click Response - Actual Request to see the request URL,
    and you'll find the {{Userid}} is replaced by the current value.



TIP

Learn more about Variables here.


PRE PROCESSORS#

In Apidog, Pre Processors are operations that are executed before a request is
sent. They allow you to manipulate the request and environment variables before
the request is sent.

Pre Processors can be used to:

 * Set or modify variables that are used in the request
 * Perform data validation or data transformation
 * Add or modify headers
 * Log information or debug data
 * Make other requests and store the response data in variables
 * Modify the request URL

These operations can be written in JavaScript, and you can use the Postman SDK
to access the request and response objects, as well as the environment and
global variables. Once a script is added, it will execute every time the request
is sent.

Here is an example to modify the request param value in Pre Processors.

 1. Click the Pre Processors tab, and click the Add PreProcessor button. Add a
    Custom Script.



 2. Paste the following script into the Custom Script area.

let Userid = parseInt(pm.environment.get("Userid"));Userid = Userid + 1;console.log(Userid);pm.environment.set("Userid", Userid);




 3. Drag the Custom Script before the Variable Substitution operation. Send the
    request.



 4. After sending, you'll see the value of {{Userid}} became 2. And if you send
    the request many times, the {{Userid}} will plus one each time sending.



 5. Public Script, Database Operation, and Wait can also be added to Pre
    Processors.



TIP

Learn more about Scripts here.


FRONT-END DEVELOPERS: API MOCKING#

API mocking is a simulated version of an API that is used for testing and
development purposes. It allows developers to test their applications or
services without relying on a live API, and can be configured to return specific
responses to incoming requests.

Based on the specified API, Apidog can generate mock data automatically without
any configuration. That's very convenient for front-end developers.

 1. Switch to the API tab and click Local Mock. Click the URL & Params of
    'OK(200)' to copy to the clipboard.



 2. Paste the URL to a browser. And you'll see a generated JSON. The data is
    dynamic; each time you reload the page, the data will refresh.
    
    Especially you'll find the data generated are reasonable according to the
    name of the node, just like 'email' or 'lastName'. This is the powerful
    Smart Mock feature of Apidog.



 3. Go to the Edit tab and Dereference the 'ApiResponse' Schema in the Response
    Part.



 4. Type the Mock value into the nodes, and Save the API.
    * code
      * 200
    * type
      * JSON
    * message
      * Success



 5. Reload the page in the browser, and you'll find the JSON data refreshed, and
    the 'code', 'type', and 'message' fields are generated according to your
    settings. Now the front-end developer can use the URL to get data in the
    client they are developing.



 6. Faker.js is also supported in the mock settings. You can select any Faker.js
    grammar to generate dynamic mock data.



 7. If you need the mock response to be fixed, go to Settings - Feature Settings
    - Mock Settings - Default Mock Type, and switch to Response Example First.
    Then Apidog mock engine will use the API response example as the mock
    response.



TIP

The mocking feature in Apidog also supports cloud mocking, returning different
mock responses for different request parameters, using scripts to rewrite mock
responses, customizing intelligent mock matching rules, and so on. Learn more
about Mocking here.


QA ENGINEERS: API TESTING#

Apidog's automated testing module allows QA engineers to directly generate test
scenarios referring API definitions or API cases. It supports data-driven
testing and easily generates dynamic test data. The visual assertion and
variable extraction features make writing test cases very simple. Apidog also
supports CI/CD.


ASSERTIONS#

In Apidog, test assertions can be added visually in Post Processors. It also
supports adding assertion statements in custom scripts using the Postman SDK.

 1. Go to Get user by id - Success, switch to Post Processors and Add
    PostProcessor - Assertion.



 2. Enter the following assertion parameters into the Assertion.
    * JSONPath Expression
      * $.code
    * Assertion
      * Equals: 200

TIP

Learn more about JsonPath here.



 3. Send the request, and you'll see the Assertion Result.
    
    Apidog will get the value of $.code from the response JSON and compare it
    with the assertion. If they match, the assertion will pass.



 4. Extract Variable, Custom Script, Public Script, Database Operation, and Wait
    can also be added to Post Processors.
    
    MySQL, SQL Server, Oracle, PostgreSQL, and ClickHouse Database are supported
    in Apidog. SQL statements can be executed, and the SELECT result can be
    extracted to variables. Other SQL like INSERT, DELETE, and UPDATE can also
    be executed.



TIP

Learn more about Database Operation here.


TEST SCENARIOS#

After writing the assertions, multiple API cases can be imported into a single
test case, run with one click, and generate a test report.

 1. Switch to the Testing module. Create a New Test Case.





 2. Enter the case. Click Add Step and select Import from API Cases.



 3. Select API cases to be imported: 'Add a new pet to the store - Success',
    'Find pet by ID - Success', 'Update an existing pet - Success'. Click OK to
    import.



 4. Click Run to execute the test case. Then you'll see a test report, and the
    details of each request.





 5. Click More to see what went wrong with the failed API and compare the
    response with the assertions to locate the problem.





TIP

Learn more about Test Cases here.


DATA-DRIVEN TESTING#

If variables are used in API cases, then the value of the variables can be set
using a data table or by using the Dynamic Value feature to automatically
generate variable values.

 1. Turn on the Test Data switch, and click Manage Data.



 2. Add variables and datasets, then values of the variables. Importing from CSV
    or JSON is also supported.



 3. Save and Run, and the values of the variables will be used in the iterations
    of the test case.





TIP

Learn more about Test Data here.


DYNAMIC VALUES#

If you need a dynamic change in parameter values for an API, you can use the
"dynamic variable" feature.

 1. Click Detail of the API case, and click the 🪄(magic wand) button to open
    the Dynamic Value dialogue.





 2. Select Datatype - number, and you'll see a preview of the dynamic value.
    Click Insert to apply the dynamic value.



 3. Dynamic values will take effect in the actual sent request. You can see the
    actual values sent in the Actual Request. Each time the request is sent, the
    dynamic value will generate a new value.



 4. Dynamic values can also be inserted into the request body in JSON or XML
    format and will also be processed as actual values when sent.



TIP

Learn more about Dynamic Value here.


CI / CD#

Apidog supports running via command line. After installing the Apidog CLI, you
can use the command apidog run to get a command line test report. This command
can also be used in Jenkins for implementing CI/CD.

 1. Click CI/CD in a test case.



 2. Set the test parameters and click save, and you will get a command line
    statement. Click Learn More to install Apidog CLI.



TIP

Learn more about CI / CD here.


API DESIGNERS & API CONSUMERS: API DOCUMENTATIONS#

After the API is designed, developed, debugged, and tested, it becomes a product
that can be called by other users. Apidog can generate beautiful API
documentation, making it easy for the development team to publish the API
outside of the team.

 1. Switch to the Share module, and +New a share.



 2. Select the environment that will be effective in the API documentation.
    Readers of the API documentation will be able to use the environment
    configured here to run the API.



 3. Open the shared docs in a browser.



 4. The API documentation is generated and can be shared on the internet. It
    also can be Try it out on the shared website.





 5. Code Samples feature supports generating API request code in dozens of
    languages, allowing API readers to directly call the API with the generated
    code.



 6. Code Generation in the Responses also supports generating code for the
    structure of the response data, supporting several dozens of languages. API
    consumers can use the generated code in their implementation.





 7. Custom domain, Top Navigation, Catalog Style, Content Footer, and more
    custom features are also supported in the documentation.




BEST PRACTICE#

 1. In Apidog, the API designer (or Back-end developer) defines the
    specifications for the API.
 2. The development team collaborates to review and improve the documentation,
    and to ensure consistency in the API use cases.
 3. Using Apidog, front-end developers can begin development with automatically
    generated mock data, eliminating the need for manual mock rule creation.
 4. Back-end developers can debug using the API use cases during development. If
    all API use cases pass during debugging, the API development is considered
    complete. If changes to the API occur during development, the API
    documentation is automatically updated during debugging, ensuring timely API
    maintenance with minimal effort.
 5. After debugging, back-end developers can easily save the function as an API
    use case.
 6. QA engineers can then test the API directly using the API use cases.
 7. Once all APIs have been developed, QA engineers (or back-end developers) can
    use the test case and test collection function to conduct comprehensive
    multi-API integration testing.
 8. Joint debugging between front-end and back-end development is typically
    seamless because both teams adhere to the API's specifications, allowing
    front-end developers to switch from mock data to real data.
 9. Once the API development is complete, Apidog generates a beautiful API
    documentation, making it easy for the development team to publish the API to
    external teams.

The above is a summary of the core features and usage of Apidog. Apidog also has
many other rich features that can help development teams efficiently develop and
debug APIs.

Modified at a month ago
CloneExport

My Apidog
📄 Contents
What is Apidog
Why Apidog
API Designers: Specify APIs
Import from OpenAPI specifications
Specify a new API
Back-end Developers: API Developing & Debugging
Generate Code
Run the API
Debugging
Use Variables
Pre Processors
Front-end Developers: API Mocking
QA Engineers: API Testing
Assertions
Test Scenarios
Data-Driven Testing
Dynamic Values
CI / CD
API Designers & API Consumers: API Documentations