-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(rest-api): Adds Swagger for api docs [SLT-205] #3159
Conversation
Warning Rate limit exceeded@abtestingalpha has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 6 seconds before requesting another review. How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes introduce new dependencies for Swagger in the REST API, enhancing API documentation capabilities. The integration of Swagger UI allows users to access interactive documentation at the Changes
Possibly related PRs
Suggested labels
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Deploying sanguine-fe with Cloudflare Pages
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3159 +/- ##
=============================================
Coverage 37.95009% 37.95009%
=============================================
Files 418 418
Lines 24245 24245
Branches 82 82
=============================================
Hits 9201 9201
Misses 14306 14306
Partials 738 738
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Bundle ReportChanges will increase total bundle size by 241.0kB (0.67%) ⬆️. This is within the configured threshold ✅ Detailed changes
ℹ️ *Bundle size includes cached data from a previous commit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
packages/rest-api/src/routes/getSynapseTxIdRoute.ts (1)
Line range hint
87-105
: Input validation looks good, consider adding a format check fortxHash
.The express-validator middleware is effectively used to validate the
originChainId
,bridgeModule
, andtxHash
query parameters. The validations ensure that the required parameters are provided and are of the correct type.The
bridgeModule
validation against theVALID_BRIDGE_MODULES
array is a nice touch, preventing invalid module values from being accepted.Suggestion:
Consider adding a format validation for thetxHash
parameter to ensure it is a valid transaction hash. You can use theisHash
validator from express-validator:check('txHash').exists().withMessage('txHash is required').isString().isHash('sha256')This will ensure that the provided
txHash
is a valid SHA-256 hash.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (4)
- packages/rest-api/src/controllers/getSynapseTxIdController.ts (1 hunks)
- packages/rest-api/src/routes/bridgeRoute.ts (1 hunks)
- packages/rest-api/src/routes/getSynapseTxIdRoute.ts (1 hunks)
- packages/rest-api/src/routes/swapRoute.ts (1 hunks)
Files skipped from review due to trivial changes (1)
- packages/rest-api/src/controllers/getSynapseTxIdController.ts
Additional context used
Gitleaks
packages/rest-api/src/routes/bridgeRoute.ts
114-114: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
124-124: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
packages/rest-api/src/routes/swapRoute.ts
79-79: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Additional comments not posted (5)
packages/rest-api/src/routes/getSynapseTxIdRoute.ts (1)
10-84
: Great job with the comprehensive OpenAPI documentation!The OpenAPI (Swagger) documentation for the
/getSynapseTxId
endpoint is thorough and well-structured. It clearly defines the endpoint details, parameters, and response schemas, making it easy for clients to understand and integrate with the API.Some notable aspects:
- The
bridgeModule
parameter is constrained to specific values using an enum, ensuring that only valid modules are accepted.- The response schemas are well-defined for both successful and error responses, providing clarity on the expected data format.
- The example responses help in understanding the actual data structure.
Overall, the documentation enhances the API's usability and maintainability.
packages/rest-api/src/routes/swapRoute.ts (3)
13-133
: LGTM!The OpenAPI documentation for the
/swap
endpoint is comprehensive and accurate. It includes:
- A clear summary and description of the endpoint's functionality.
- Definitions for all required query parameters with their types and descriptions.
- Response schemas for the relevant HTTP status codes (200, 400, 500) with detailed information about the response structure.
- A
BigNumber
schema correctly defined in the components section.Great job documenting the endpoint!
Tools
Gitleaks
79-79: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Line range hint
134-169
: LGTM!The implementation of the
/swap
endpoint is robust and follows best practices:
- The route definition and path are correct.
- The
checksumAddresses
middleware is used to validate thefromToken
andtoToken
addresses.- Express validator is utilized to perform comprehensive validations on the query parameters, including:
- Checking for the existence and numeric type of the
chain
parameter.- Verifying the existence, valid token address format, and support on the specified chain for the
fromToken
andtoToken
parameters.- Ensuring the existence and numeric type of the
amount
parameter.- Custom validators are employed to check token support on the specified chain, enhancing data integrity.
- The
showFirstValidationError
middleware is used to handle validation errors and provide meaningful error responses to the client.- The
swapController
is correctly set as the route handler.The implementation looks solid and well-structured.
Tools
Gitleaks
79-79: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
79-79
: Gitleaks hint is a false positive.The value flagged by Gitleaks on line 79 is not an API key but an Ethereum address used in the example response for the OpenAPI documentation. Ethereum addresses are publicly visible on the blockchain and do not represent sensitive information.
You can safely ignore this hint as a false positive.
Tools
Gitleaks
79-79: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
packages/rest-api/src/routes/bridgeRoute.ts (1)
13-187
: Excellent OpenAPI documentation for the new/bridge
endpoint!The documentation is comprehensive and well-structured, covering the following aspects:
- Clear summary and description of the endpoint's purpose
- Well-defined required query parameters with appropriate types and descriptions
- Detailed response structure for success (200) and error (400, 500) cases
- Usage of the
BigNumber
schema for consistent representation of numeric values- Informative example response illustrating the expected format
- Structured error responses with details about the nature of the error
This documentation will greatly enhance the usability and understanding of the API for developers.
Tools
Gitleaks
114-114: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
124-124: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Some non-critical ideas: How do we feel about having users land on the api-docs page instead of the get api information? Which is more helpful to users? Also should we rename the tx status endpoints to remove the "get" ie: otherwise looks good to me |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 5
Outside diff range and nitpick comments (1)
packages/rest-api/src/routes/destinationTxRoute.ts (1)
1-122
: LGTM! The code segment introduces a well-documented and validated API endpoint.The code segment follows best practices for defining an Express route and incorporates OpenAPI documentation for improved API discoverability. The validation checks ensure that the required parameters are provided and have the correct data types.
A few additional suggestions:
- Consider adding a more specific error message for the
txHash
validation, similar to theoriginChainId
validation. For example, "txHash must be a string".- If the
destinationTxController
function performs any asynchronous operations, make sure to handle errors appropriately and send a 500 response with a meaningful error message.- Consider adding a rate limiting middleware to prevent abuse of the API endpoint.
Overall, the code segment looks good and follows best practices for API development.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (15)
- packages/rest-api/src/controllers/bridgeTxStatusController.ts (2 hunks)
- packages/rest-api/src/controllers/destinationTxController.ts (2 hunks)
- packages/rest-api/src/controllers/synapseTxIdController.ts (2 hunks)
- packages/rest-api/src/routes/bridgeTxInfoRoute.ts (1 hunks)
- packages/rest-api/src/routes/bridgeTxStatusRoute.ts (1 hunks)
- packages/rest-api/src/routes/destinationTxRoute.ts (1 hunks)
- packages/rest-api/src/routes/getBridgeTxStatusRoute.ts (0 hunks)
- packages/rest-api/src/routes/getDestinationTxRoute.ts (0 hunks)
- packages/rest-api/src/routes/index.ts (2 hunks)
- packages/rest-api/src/routes/indexRoute.ts (1 hunks)
- packages/rest-api/src/routes/swapTxInfoRoute.ts (1 hunks)
- packages/rest-api/src/routes/synapseTxIdRoute.ts (1 hunks)
- packages/rest-api/src/tests/bridgeTxStatusRoute.test.ts (6 hunks)
- packages/rest-api/src/tests/destinationTxRoute.test.ts (3 hunks)
- packages/rest-api/src/tests/synapseTxIdRoute.test.ts (6 hunks)
Files not reviewed due to no reviewable changes (2)
- packages/rest-api/src/routes/getBridgeTxStatusRoute.ts
- packages/rest-api/src/routes/getDestinationTxRoute.ts
Additional comments not posted (30)
packages/rest-api/src/controllers/synapseTxIdController.ts (2)
5-5
: LGTM: The function name change improves clarity and conciseness.Removing the "get" prefix aligns the function name with the endpoint and makes it more concise.
24-24
: LGTM: The error message update maintains consistency with the endpoint name.Updating the error message to reference
/synapseTxId
ensures consistency with the updated endpoint name.packages/rest-api/src/routes/index.ts (2)
8-10
: Verify the route usage changes.The import renaming looks good and aligns with the objective to remove the "get" prefix for clarity. Please ensure that the route usage has been updated accordingly.
21-23
: LGTM!The route usage changes are consistent with the import renaming and fulfill the objective of removing the "get" prefix for conciseness. The updated routes look good.
packages/rest-api/src/controllers/destinationTxController.ts (1)
6-6
: LGTM!The function rename from
getDestinationTxController
todestinationTxController
aligns with the suggested naming convention to remove the "get" prefix for clarity and conciseness. The error message update ensures consistency with the new endpoint name.These changes improve the overall clarity and consistency of the API without introducing any breaking changes.
Also applies to: 68-68
packages/rest-api/src/controllers/bridgeTxStatusController.ts (2)
7-7
: LGTM: The function name change improves clarity.Removing the
get
prefix from the function name aligns with the suggestion made in the PR comments and enhances the clarity of the endpoint. The change does not impact the functionality.
75-75
: LGTM: The error message update maintains consistency.Updating the error message to reflect the new function name
/bridgeTxStatus
ensures consistency and prevents confusion. This change accurately communicates the endpoint in the error message.packages/rest-api/src/tests/destinationTxRoute.test.ts (4)
4-4
: LGTM!The import statement has been correctly updated to reflect the renamed route file. This change aligns with the objective to streamline the endpoint names by removing the "get" prefix.
7-7
: LGTM!The route definition has been correctly updated to use the streamlined
/destinationTx
path and the renameddestinationTxRoute
handler. This change enhances the clarity and conciseness of the endpoint.
11-11
: LGTM!The test case has been correctly updated to make a request to the new
/destinationTx
endpoint. The change is consistent with the route definition update and maintains the integrity of the test.
33-33
: LGTM!All the test cases have been consistently updated to make requests to the new
/destinationTx
endpoint. The changes are in line with the route definition update and maintain the integrity of the tests.Also applies to: 42-42, 50-50
packages/rest-api/src/tests/synapseTxIdRoute.test.ts (8)
4-4
: LGTM!The import statement has been correctly updated to match the new route path.
7-7
: LGTM!The route path has been correctly updated to
/synapseTxId
.
11-11
: LGTM!The test case has been correctly updated to use the new route path
/synapseTxId
.
22-22
: LGTM!The test case has been correctly updated to use the new route path
/synapseTxId
.
32-32
: LGTM!The test case has been correctly updated to use the new route path
/synapseTxId
.
42-42
: LGTM!The test case has been correctly updated to use the new route path
/synapseTxId
.
51-51
: LGTM!The test case has been correctly updated to use the new route path
/synapseTxId
.
62-62
: LGTM!The test case has been correctly updated to use the new route path
/synapseTxId
.packages/rest-api/src/tests/bridgeTxStatusRoute.test.ts (8)
4-4
: LGTM!The import statement has been correctly updated to match the new route path.
7-7
: LGTM!The route path in the
app.use
statement has been correctly updated to/bridgeTxStatus
.
11-11
: LGTM!The route path in the
request(app).get
statement has been correctly updated to/bridgeTxStatus
.
31-31
: LGTM!The route path in the
request(app).get
statement has been correctly updated to/bridgeTxStatus
.
45-45
: LGTM!The route path in the
request(app).get
statement has been correctly updated to/bridgeTxStatus
.
59-59
: LGTM!The route path in the
request(app).get
statement has been correctly updated to/bridgeTxStatus
.
68-68
: LGTM!The route path in the
request(app).get
statement has been correctly updated to/bridgeTxStatus
.
78-78
: LGTM!The route path in the
request(app).get
statement has been correctly updated to/bridgeTxStatus
.packages/rest-api/src/routes/indexRoute.ts (1)
7-82
: Excellent work on adding OpenAPI documentation for the root route!The OpenAPI specification for the root route (
/
) is well-structured and comprehensive. It provides a clear description of the endpoint's functionality, including the request and response details.Some key highlights:
- The summary and description give a good overview of the endpoint's purpose.
- The successful response (HTTP 200) schema is well-defined, including the message, available chains, and available tokens.
- The server error response (HTTP 500) schema is also properly documented.
- The example provided for the successful response helps in understanding the expected response format.
This documentation will greatly improve the API's usability and make it easier for developers to understand and interact with the endpoint.
packages/rest-api/src/routes/synapseTxIdRoute.ts (1)
1-107
: LGTM!The code segment introduces a new Express route for retrieving a Synapse transaction ID. The implementation follows best practices and includes:
- Comprehensive OpenAPI documentation
- Proper parameter validation using
express-validator
- Custom error handling middleware
- Separation of route definition and controller logic
The code is well-structured, maintainable, and enhances the functionality and usability of the API.
packages/rest-api/src/routes/bridgeTxStatusRoute.ts (1)
1-145
: LGTM!The code segment follows best practices and provides a well-documented and validated API endpoint for getting the status of a bridge transaction. The use of OpenAPI (Swagger) for documentation,
express-validator
for input validation, and a separate controller function promotes modularity and enhances the usability and reliability of the endpoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
Outside diff range and nitpick comments (2)
packages/rest-api/src/routes/bridgeRoute.ts (2)
20-49
: Consider changingamount
parameter type to string for precision.In the OpenAPI documentation, the
amount
parameter is specified withtype: number
. For financial amounts, especially large integers or values requiring high precision, it's common to use a string to prevent precision loss in JSON. Consider changing theamount
type tostring
to accurately represent large or precise values.
13-187
: Maintain consistent formatting and indentation in documentation.The OpenAPI documentation comments should have consistent indentation for better readability. Uniform formatting helps in maintaining the documentation and makes it easier for other developers to understand and contribute.
Tools
Gitleaks
114-114: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
124-124: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (8)
- packages/rest-api/src/routes/bridgeRoute.ts (1 hunks)
- packages/rest-api/src/routes/bridgeTxInfoRoute.ts (1 hunks)
- packages/rest-api/src/routes/bridgeTxStatusRoute.ts (1 hunks)
- packages/rest-api/src/routes/destinationTokensRoute.ts (1 hunks)
- packages/rest-api/src/routes/destinationTxRoute.ts (1 hunks)
- packages/rest-api/src/routes/swapRoute.ts (1 hunks)
- packages/rest-api/src/routes/swapTxInfoRoute.ts (1 hunks)
- packages/rest-api/src/routes/synapseTxIdRoute.ts (1 hunks)
Files skipped from review as they are similar to previous changes (5)
- packages/rest-api/src/routes/bridgeTxInfoRoute.ts
- packages/rest-api/src/routes/bridgeTxStatusRoute.ts
- packages/rest-api/src/routes/destinationTxRoute.ts
- packages/rest-api/src/routes/swapTxInfoRoute.ts
- packages/rest-api/src/routes/synapseTxIdRoute.ts
Additional context used
Gitleaks
packages/rest-api/src/routes/bridgeRoute.ts
114-114: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
124-124: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
packages/rest-api/src/routes/swapRoute.ts
79-79: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Additional comments not posted (7)
packages/rest-api/src/routes/destinationTokensRoute.ts (2)
14-97
: Excellent work on the OpenAPI documentation!The documentation for the
/destinationTokens
endpoint is comprehensive and well-structured. It clearly describes the endpoint's functionality, required parameters, and possible responses. The examples provided for the successful response and error cases are helpful for understanding the API's behavior.The documentation follows the OpenAPI specification and covers all the essential aspects of the endpoint. Great job!
Line range hint
98-130
: The route handler and middleware implementation look solid!The route handler for the
/destinationTokens
endpoint is well-structured and makes use of appropriate middleware functions. ThechecksumAddresses
middleware ensures that thefromToken
address is properly checksummed, which is a good practice.The validation checks using the
check
middleware are comprehensive and cover all the necessary aspects of the request parameters. The custom validation functions, such asisTokenAddress
andisTokenSupportedOnChain
, provide additional safeguards to ensure the validity of the input.The
showFirstValidationError
middleware is used to handle validation errors and provide meaningful error responses to the client.Overall, the route handler and middleware implementation follow best practices and ensure the integrity of the API endpoint.
packages/rest-api/src/routes/swapRoute.ts (3)
13-133
: Excellent OpenAPI documentation!The OpenAPI documentation for the
/swap
endpoint is comprehensive and well-structured. It provides a clear summary and description of the endpoint's functionality. The required query parameters are properly defined with their types and descriptions. The response schemas are well-documented for different status codes, including example responses. The customBigNumber
schema is also correctly defined in the components section.Great job on providing thorough and accurate API documentation!
Tools
Gitleaks
79-79: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Line range hint
134-169
: Robust request parameter validation and error handling.The endpoint implements comprehensive request parameter validation using the
express-validator
middleware. The custom validators forchain
,fromToken
, andtoToken
ensure that the provided values are valid, supported, and compatible with each other. Theamount
parameter is also validated for existence and numeric type.The
showFirstValidationError
middleware is used to handle validation errors and return appropriate error responses to the client.The request validation and error handling implementation is robust and follows best practices.
Tools
Gitleaks
79-79: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
79-79
: False positive: Generic API key hint can be ignored.The static analysis hint flagging line 79 as a potential generic API key exposure is a false positive. The flagged value
"0x7E7A0e201FD38d3ADAA9523Da6C109a07118C96a"
is not an actual API key but an example Ethereum address used in the OpenAPI documentation.The static analysis tool likely flagged it due to the hexadecimal format resembling an API key. However, no sensitive information is being exposed in this case, and the hint can be safely ignored.
Tools
Gitleaks
79-79: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
packages/rest-api/src/routes/bridgeRoute.ts (2)
182-186
: EnsureBigNumber
schema is comprehensive for client reconstruction.The
BigNumber
schema is defined withtype
andhex
properties. Verify that these fields are sufficient for clients to reconstructBigNumber
instances accurately. If additional properties or examples are necessary for clarity, consider including them.
63-64
: Verify the reference toBigNumber
schema.Ensure that the
$ref: '#/components/schemas/BigNumber'
correctly points to the definedBigNumber
schema in your OpenAPI specification. This helps in avoiding any unresolved references when the OpenAPI document is processed.You can run the following script to check for unresolved references:
Verification successful
BigNumber schema reference is correct and properly used.
The verification process confirms that the
$ref: '#/components/schemas/BigNumber'
reference is correctly defined and used in the OpenAPI specification. The BigNumber schema is properly defined in bothbridgeRoute.ts
andswapRoute.ts
files, and it is consistently referenced throughout the codebase. No issues were found with this reference.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Validate the OpenAPI specification for unresolved references. # Install swagger-cli if not already installed # npm install -g swagger-cli # Validate the OpenAPI document swagger-cli validate path/to/your/openapi.yamlLength of output: 127
Script:
#!/bin/bash # Find OpenAPI specification files echo "OpenAPI specification files:" fd -e yaml -e json -e yml --exec echo {} # Search for BigNumber schema definition echo -e "\nBigNumber schema definition:" rg -n "BigNumber:" -A 10 # Search for BigNumber schema references echo -e "\nBigNumber schema references:" rg -n '\$ref:.*BigNumber'Length of output: 20476
* update bl * remove global solidity extension settings * use monorepo support in global workspace only * - use Solidity extension for formatting *.sol files - use `forge fmt` as formatter in Solidity extension * REST API Improvements [SLT-179] (#3133) * fix swaptxinfo function * Updates test coverage command * migrating to using token addresses instead of symbols * fix linting errors * fixing swaptxinfocontroller * new tests and new functionality --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/rest-api@1.0.75 - @synapsecns/synapse-interface@0.38.4 * fix harmony proxy (#3149) Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> * merging rfq indexer into monorepo [SLT-164] [SLT-176] (#3136) * merging rfq indexer into monorepo * nuke .env * fix commands * fix package name * test coverage script * rough pass at docs and some linting and fixes yarn * Upgrades wagmi & rainbowkit * indxer * Adds invisible but used packages * +recent-invalid-fills [SLT-188] * Moves wagmi to root * new endpoints and clean up linting --------- Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> Co-authored-by: parodime <jordan@protochainresearch.com> * Publish - @synapsecns/synapse-interface@0.38.5 - @synapsecns/rfq-indexer-api@1.0.2 - @synapsecns/rfq-indexer@0.0.2 * Adds /destinationTokens route [SLT-204] (#3151) * Adds /destinationTokens route * ZeroAddress & NativeGasAddress * Adds test for native gas tokens * Checksums incoming token address params * Publish - @synapsecns/rest-api@1.0.76 * boba pause (#3150) * boba pause * only boba to txns * Publish - @synapsecns/synapse-interface@0.38.6 * fix(synapse-interface): Reorders validation to check existence first (#3156) * Reorders validation to check existence first * Removes duplicates * Publish - @synapsecns/rest-api@1.0.77 * Fix boba pause (#3158) * Publish - @synapsecns/synapse-interface@0.38.7 * update bl * feat(rest-api): Adds Swagger for api docs [SLT-205] (#3159) * Adds Swagger for api docs * Replace prepended verb Get routes with nouns * Adds dev flag for swagger serverUrl * Publish - @synapsecns/rest-api@1.1.0 - @synapsecns/synapse-interface@0.38.8 - @synapsecns/rfq-indexer-api@1.0.3 - @synapsecns/rfq-indexer@0.0.3 * Pulls version from package json (#3160) * Publish - @synapsecns/rest-api@1.1.1 * Require vs import due to file location (#3161) * Require vs import due to file location * Publish - @synapsecns/rest-api@1.1.2 * Prevent caching of api docs (#3162) * Publish - @synapsecns/rest-api@1.1.3 * feat(contracts-rfq): relay/prove/claim with different address [SLT-130] (#3138) * init. solidity ^. FbV2 relay/prove/claim overloads * +IFastBridgeV2, explicit address0 cast, func scope & inheritdoc fixes * pragma lock, contract relabel * feat: start scoping V2 tests * test: override relayer role scenarios, no longer enforced by V2 * test: finish the parity test * test: the management methods * test: dst chain scenarios * test: bridge * test: prove * test: claim * test: dispute * test: refund * test: bridge reverts * remove redundant extend. rearrange inherit list * revert 0.8.20 in favor of user (non-ws) setting --------- Co-authored-by: ChiTimesChi <88190723+ChiTimesChi@users.noreply.github.com> * Publish - FastBridge@0.4.0 * fix(promexporter): make spans better (#3164) * move the errors * [goreleaser] * fix v to w * changing native token address standard [SLT-210] (#3157) * changing native token address standard * fixing tests * normalizeNativeTokenAddress middleware, additional tests --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/rest-api@1.1.4 * Refactoring rfq-indexer API and adding swagger docs [SLT-228] (#3167) * refactoring and adding swagger * remove testing scripts * fix typos and consistency with 404 errors * Publish - @synapsecns/rfq-indexer-api@1.0.4 * fix read mes (#3168) * Publish - @synapsecns/contracts-core@1.0.32 - FastBridge@0.4.1 - @synapsecns/solidity-devops@0.4.5 * fix(opbot): use submitter get tx status [SLT-158] (#3134) * use experimental logger to debug * fix lint * [goreleaser] * use submitter instead of client * [goreleaser] * [goreleaser] * fix(synapse-interface): Additional checks on screen [SLT-166] (#3152) * Additional checks on screen * Adds checks on chain/token changes * Publish - @synapsecns/synapse-interface@0.38.9 * feat(synapse-interface): confirm new price [SLT-150] (#3084) * add bridge quote history middleware * request user confirm changes when quoted price updates * add conditions for displaying confirm change state * track initial quote initializing confirm change state * specify output delta threshold * callback functions to handle initialize/accept/reset confirm changes flow * quote countdown timer animation to signal refresh * implement automatic refresh intervals * mouse move to refresh automatic intervals * add i8n translations for button text --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/synapse-interface@0.39.0 * fix: formatted bridge fee amount (#3165) * Publish - @synapsecns/rest-api@1.1.5 * fix(contracts-rfq): CI workflows [SLT-245] (#3178) * fix: license, files * fix: package name * build: update solhint to latest * build: remove prettier dependencies * fix: solhint workflows * build: update solhint in other packages as well * chore: solhint rules, exceptions * fix: silence linter warnings in tests * chore: forge fmt * add variable to test linter CI * Revert "add variable to test linter CI" This reverts commit 0629309. * Publish - @synapsecns/contracts-core@1.0.33 - @synapsecns/contracts-rfq@0.5.0 - @synapsecns/solidity-devops@0.4.6 * feat(api): bridge limits [SLT-165] (#3179) * adds `/bridgeLimits` route, controller * fetch best sdk quote for min/max origin amounts * add tests * implement middleware to normalize addresses * adds swagger doc * Publish - @synapsecns/rest-api@1.2.0 * fix(contracts-rfq): limit the amount of solhint warnings [SLT-245] (#3182) * ci: limit the amount of solhint warnings * refactor: move the errors into the separate interface * refactor: errors imports in tests * Publish - @synapsecns/contracts-rfq@0.5.1 * ci: Solidity gas diff [SLT-259] (#3181) * ci: run tests w/o coverage first for better visibility * test: malform the test to check the adjusted workflow * Revert "test: malform the test to check the adjusted workflow" This reverts commit e7db6e1. * ci: add gas-diff workflow * try changing the contract to trigger gas diffs * retrigger the workflow * ci: provide the correct report path * ci: run on pull requests only * ci: save gas reports in monorepo root * Revert "ci: run on pull requests only" This reverts commit 0a01d60. * Revert "try changing the contract to trigger gas diffs" This reverts commit 91bc03e. * refactor: wrap if statement * refactor: exclude `solidity-devops` package in a more generic way * ci: run tests w/o coverage for `solidity-devops`, add comments * add generic comment to trigger `solidity-devops` workflows * Revert "add generic comment to trigger `solidity-devops` workflows" This reverts commit cc35a43. * Publish - @synapsecns/contracts-rfq@0.5.2 * fix(contracts-core): set very high gas limit for intensive tests [SLT-259] (#3186) * fix: set very high gas limit for intensive tests * ci: speed up solidity coverage * Publish - @synapsecns/contracts-core@1.0.34 * feat(rest-api): Adds validateRouteExists validation [SLT-260] (#3180) * Adds validateRouteExists validation * Remove timeouts for 400s * Publish - @synapsecns/rest-api@1.3.0 * add duplicate command warning (#3174) Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> * reduce solhint warnings on FbV2 (#3189) * reduce solhint warnings on FbV2 * fix whitespace * Publish - @synapsecns/contracts-rfq@0.5.3 * ci: solidity gas diff options [SLT-267] (#3193) * ci: ignore test files in gas diff report * add some changes to the test files * ci: define some options for gas-diff * try changing the contract to trigger gas diffs * Revert "try changing the contract to trigger gas diffs" This reverts commit 4504e3c. * Revert "add some changes to the test files" This reverts commit 7e7d6cb. * prove w/ tx id [SLT-181] (#3169) * prove w/ tx id SLT-181 * +proveOther tests, forge fmt * fmt * fmt * Publish - @synapsecns/contracts-rfq@0.5.4 * fix(sdk-router): disable ARB airdrop tests (#3195) * Publish - @synapsecns/rest-api@1.3.1 - @synapsecns/sdk-router@0.11.2 - @synapsecns/synapse-interface@0.39.1 - @synapsecns/widget@0.7.2 * Fixing issue for wallet integration [SLT-270] (#3194) * slight modification to graphql call * fixing explorer frontend as well * Publish - @synapsecns/explorer-ui@0.3.3 - @synapsecns/rest-api@1.3.2 * store relayer on relay [SLT-182] (#3170) * store relayer on relay [SLT-182] * +tests, zeroAddr check, fmt * Publish - @synapsecns/contracts-rfq@0.5.5 * Adjust text to trigger build (#3199) * Publish - @synapsecns/synapse-interface@0.39.2 * feat(synapse-interface): refund RFQ transaction [SLT-272] (#3197) * Txn transaction refund tracking * Update store to support tracking * Query FastBridge contract for `bridgeStatuses` to find refund status * Track bridge transaction `bridgeQuote.routerAddress` in store * Fetch FastBridge contract address when only provided router address * add translations --------- Co-authored-by: aureliusbtc <82057759+aureliusbtc@users.noreply.github.com> Co-authored-by: ChiTimesChi <88190723+ChiTimesChi@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> Co-authored-by: Defi-Moses <Defi-Moses@users.noreply.github.com> Co-authored-by: trajan0x <83933037+trajan0x@users.noreply.github.com> Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> Co-authored-by: parodime <jordan@protochainresearch.com> Co-authored-by: abtestingalpha <104046418+abtestingalpha@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@users.noreply.github.com> Co-authored-by: parodime <parodime@users.noreply.github.com> Co-authored-by: vro <168573323+golangisfun123@users.noreply.github.com> Co-authored-by: ChiTimesChi <ChiTimesChi@users.noreply.github.com> Co-authored-by: bigboydiamonds <57741810+bigboydiamonds@users.noreply.github.com> Co-authored-by: bigboydiamonds <bigboydiamonds@users.noreply.github.com>
Description
/api-docs
/destinationTokens
endpointSummary by CodeRabbit
New Features
/api-docs
./bridge
endpoint to retrieve quotes for bridging tokens./synapseTxId
endpoint to retrieve Synapse transaction IDs./swap
endpoint to provide detailed swap quotes.Improvements
These changes enhance usability and provide developers with interactive documentation for better API integration.