Improvement - Unsolicited Design Ideas/ SRT feedback #5
Description
As this is a new project, I'd like to provide some design suggestions that SRT would benefit from. I realize that this may not be easily implemented and it's kind of looking like this project is to define the current API that exists. If building something new that SRT can easily use.
Authentication:
Looking at the current example in the repo it appears to be using the shared-session-com.synack.accessToken. SRT would benefit from being able to have an actual API key.
- SRT will no longer need to perform automation to obtain the token
- The API key will not be short lived or be tied to the session needing it to be refreshed - ideal for automation.
- Ease of use leads to better adoption
Assets and the use of Slugs
Looking at the provided example an SRT would need to know two Uid tied to an asset to make the query.
listingUid[]= &organizationUid[]=
For ease of use an abstraction layer based on codename would help instead of forcing users to perform additional queries to get information.
SRT know projects by codenames so it makes sense to use those .. but I like the word project so using that as an example.
/api/srt/project/rancidemellon-w013/scope
Based on the rancidemellon-w013 it should be possible to retrieve the org and project slug as well as if it is a web target. Then the other query can be made under the hood.
Could have an endpoint like above that returns all scope and then additional endpoints like below for in and out.
/api/srt/project/rancidemellon-w013/scope/in
/api/srt/project/rancidemellon-w013/scope/out
Take params for sort.