Open nasbench opened 11 months ago
@nasbench If we intend to introduce API Endpoints I think we should keep it more REST like.
These would be my suggestions for changes:
get
in the url path aswell. That seems to be redundant for me./api/v1/
in before. That makes it more easy to add breaking changes later by introduction a new version /api/v2/
(if needed)Here some examples of how I imagine it:
URL | Response |
---|---|
/api/v1/backends |
List of all backend with identifier and description (same information like in sigma list targets ) |
/api/v1/formats?backend=splunk |
Return all formats for the splunk backend with name and description (same information like in sigma list formats splunk ) |
/api/v1/formats |
Return all formats for the backends with name and description (same information like in sigma list formats <backendname> ) + the backend name for the specific format |
/api/v1/pipelines |
List of all available pipelines (same information like in sigma list pipelines ) |
/api/v1/pipelines?backend=splunk |
only return pipelines which have all or splunk in the allowed backends list |
Let me know what you think
You went for the more official route :) My idea was just to do a quick API endpoints to get the data.
But no worries, I'll make the changes to make REST like a little bit. Thanks for the suggestion.
This PR adds a couple of API endpoints to make it easy to integrate sigconverter into projects.
/getbackends
endpoint to list available backends/getformats
endpoint to list available formats per backend/getpipelineallowedbackend
endpoint to list the allowed backends for every pipelineFYI: These will be used by the sigma vscode extensions