Look at the code in
pattern/apply.go we use
utils.ParseGithubURL() which eventually returns “repo link” and “path to the file”.
So why do we handle this on the client-side not on the server side.
*originally answered by @utkarsh-pro *
Because "path"can’t be exactly encoded in a URL. You can see the end
/** right? That basically tells the API to recursively scan the current path, ie. go and get all the patterns that are in the child nodes. Such globs are usually not part of the URL. If a user just gives “dir1/dir2” then the API won’t recursive scan the directories, rather will just pick the files from the root node only. More glob patterns can be supported in the future, so that a user can precisely tell what files are to be scanned.
The design is more about what is yet to come and what is already here
The goal is to be able to support more remote git repositories and we cannot rely on all of them to have same URL structure. Hence, we need to standardize this.
This API is indeed quite complex because we had to fit in a lot of features and yet keep it short and concise.
For instance this API supports:
- Importing and saving patterns from any http endpoint, so yes you can give
https://xyz.abc/file.yamland it will work.
- Importing patterns from github (in future more remote git repo) with support for scanning.
- Support for private repositories
- Multiple output formats. Two output format supported right now are cytoscape and YAML.
- Raw pattern files (as YAML)
- Optional saving, which is quite unique to this API
Fitting everything in a single API made it quite complex
Maybe to your dismay, we had plans to bundle more things here. But we decided against it