mvextensions
[BUG] Inconsistent RestFS API
The RESTFS API has two different response formats for the 'dir' API command. In extension.ts, the results from the 'dir' command are returned as an array in the 'Directories' property. In RestFS.ts, the results from the 'dir' command are returned as an array in the 'Files' property.
When implementing a RestFS endpoint, how is the server to determine which response format to return? Should it return both 'Directories' and 'Files' properties, with identical content?
Extension version 1.85 (CHANGELOG.md)
I would like to propose that the 'dir' REST command return an 'items' array, instead of either 'files' or 'directories'. And if its not too difficult at this stage, perhaps the 'file' REST command should return an 'item' array instead of 'ProgramLines'. This might make more sense, if, for example, we wanted to create a "dictionary editor" extension in the future, where the content returned is not a program, but just the contents of a record.
The current implementation of the extension excludes .Lib files from the initial directory list. I propose that the REST server should exclude unwanted files (or include desired files) on the server side, using a query string in the GET URL to limit the results, with generic "types" to either include, exclude or limit the size of the results. Something like include=source&exclude=system,object,hidden&max_items=1000. This actual query string could be derived from options set in the workspace, or other configuration.
A POST 'file' command assigns the body to the json property which sets the request Content-Type header to 'application/json'. It makes sense to assume, missing an explicit 'Accept' header, that the response from the REST server should also be 'application/json'.
If the REST server proved useful for other client applications, we might want to consider other Content-Types like 'application/octet-stream' (raw binary record data) or 'application/multivalue' to return a nested json array based on the standard MultiValue delimiters (@AM, @VM, @SVM).
Hi Pete,
The initial REST design was 2 level approach with a list of directories at the first level and program data at the second. Although there are 2 classes, File and Directories, the structure is exactly the same. How ever there is a Type parameter which can contain a 1 for directory and 2 for files. When the extension is initialized, the returned JSON currently just creates directories but files could be created with a small check to Type. When a directory is opened, the File list is returned and the current code will create both files and directories depending on the type. The only issue is the recursive nature of the directories within directories is not handled by the current FileSystem. If you can give me some indication of the structure you are looking for, I will check to see what changes need to be mad
