Where can I find api documentation for projects/folders?

I didn't find anything that was explicitly referencing projects, I *THINK* that the listFilesystemFolder and broseFolder endpoints may be what I need to explore, but I was hoping to get explicit confirmation. I'm hoping to write a FUSE interface for browsing/saving operations etc, taking a very slightly lower layer approach similar to the one in repetier-monitor. However my workflow depends on projects which I put the stl and gcode in (I have several printers but all homogeneous), and a project allows me to target one/some/all of them without having to associate the gcode with a particular printer or go through Direct Print, and I would like to be able to have a similar uploading workflow as repetier-monitor gives me. (LOVE that piece of software btw) As a side note, I'm a recent customer and have fallen in love with repetier-server-pro and it's feature set. I was wondering if you had any sort of (quasi-)official submission mechanism for contributed code. I've also been working up a API client library (initially in Python but I hope to port it to Go as well) and I noticed a lack of language sdk's for the api, so I was hoping to help change that.

Comments

  • The API is incomplete in description. I'm currently rewriting it with better format and also more complete.

    At the moment best solution is to play in web gui with debug tools open. In network tab search the socket file (eventually reload when tab was not open on load). All project commands start with "project" so you can use that as filter. Then just do what you want to copy and see what happens in messages subtab. Basically there is a root folder for each server that you fetch and whose id you use to move deeper or to check project contents. All helper functions use the ids to fetch or manuipulate data.
  • Brilliant! That shines a light down the right path, thank you so much.
  • I've got a working client library that is reasonably usable for controlling individual printers, written for python3, I'm building out the project portion of the api now, which will get the lib to a state of being usable for my other projects. I'll get repos setup on GitHub in the near future and link them here. I've also been putzing around with putting together Go and V versions of the library as well. The clients currently are using the REST interface, but I'm toying with a websocket version as well (at least for the Python version atm)
  • Sounds good. Please let us know - then we might add a 3rd party part in docs so others are more likely able to find them.
  • I've got a working start on the library in Go, I'll be making a python binding to it once it's finished. Work has kind of stalled at the moment due to life pressures, but I'll be getting back to it soon. It is usable for info lookups, and basic control / movement. I'm focusing on a 1:1 mapping of the API at first, then I'm planning on some abstractions on top of that. Anyway, the code can be found at: https://github.com/fuzzy/repetier and it will be the future home of the Py bindings as well. I've been toying with the idea of adding other language bindings as well, on my list of potentials are Ruby, Lua and Wren.
  • Just in case you need it, at https://prgdoc.repetier-server.com/ we have an improved beta of our programming docs. Contains already more information than the official one.
  • Oh fantastic! Thanks for the pointer
  • So I kind of switched directions after perusing the new docs for a bit.

      I was wondering if there was a way to get you to generate that documentation as static pages? I realized that with the new docs being much more complete, I could parse them and generate the client API stubs. So I wrote some quick Python that hit the URL and tried to parse it, but it's generated mostly on-the-fly by JS.

      I got around that easily enough of course by using a browser to save the pages, and got to parsing. That went a bit further and I have it generating a complete (non-stubbed) client library in Python (that I admittedly haven't started getting into the CI setup and testing yet).

      If the parameters section of each method specifically could get a defined format and be more consistent (as it stands I still need to manually check the output and validate it because some `parameters:` lines are inconsistent), I could easily be generating libraries for typed languages as well. I've got it generating an AST and I'm fixing up the API so it'll be easy to extend to more languages later on.
  • Actually it is a bunch of static files that get loaded by the docsify parser. Check https://prgdoc.repetier-server.com/v1/docs/_sidebar.md as entry point. It references all other markup files which might be easier to parse.

    Regarding consistency, I did not try to be extra precise and I might decide a change might be due any time. Also for new entries I normally copy/paste blocks so they are of similar structure. For example we are considering to make the responses like typescript interfaces instead of examples of returned data. Also that might help in your case it is just to show that it is not that static, also I try to be to make it easier to understand.
  • Wrt/ the consistency comment, I suppose some clarification would help.

    This format, which is the vast majority of the instances is beautiful. I can get the param name, type, and description super easily.

    ```
    Parameter: name (string) = script name.
    ```

    There is however a small number of them that don't follow that format leading to the necessity for manual checks or cleverer code than I think I'm keen to tackle at the moment.
  • I think I know that you mean. When I got too many parameter I changed it to a list I think.
  • Btw, not trying to butter anyone up or anything, but I would like to take a moment to say thanks for the work on Repetier. I've been finding the feature set quite comprehensive, and I think it's one of the more worthwhile software purchases I've made.
  • Also for the record, I've found that I can use selenium (https://selenium-python.readthedocs.io/) to render the web pages to parse, so the request for a static version is pretty moot.
  • Yes, but now you know the static pages as well you have a choice.
Sign In or Register to comment.