API between plugins - best practice?

Development
1

Hi.

I like to add a generic API to my plugin that other developers can register plugins and get some specific data back.

The easiest way for me is to add some functions in python and in my opinion it is not necessary to publish it to the outside world…like calling OctoPrint functions.

If there perhaps a best practice available how to implement this (like everybody build this in his plugin :slight_smile: ) or is it much better to implement this as a Rest API?

Cheers,
Nils

2

It depends on what the goal is. If you want external clients (such as smartphone apps) to access the plugin, then the REST API is the way forward. OctoPrint's server should never call its own REST API from the Python side, if you need plugin-to-plugin communication on the server side then helpers are the way to go:

https://docs.octoprint.org/en/master/plugins/helpers.html

1 Like
3

I overlooked helpers section, did not linked this name with this. Perfect.

Also good to know with Rest as I found such implementation often in the plugins I looked for some ideas how this could be realised.

4

Depending on your provided data you can also "push" the data to other plugins.
So, instead that the 3rd party plugin needs to activly read/pull the data, you can fire an event with a payload thru the eventbus. Other plugins can then listen for such event.

I use this approach in my DisplayLayerPlugin: https://github.com/OllisGit/OctoPrint-DisplayLayerProgress#events

Read the offical documentation how to use it, because I didn't use the register function (my implementation started with OP V1.3.0 and I never updated to this approach)

BR
Olli

1 Like
5

Bed Level Visualizer plugin has the event registration as example of the current methods here and fired here. It also has examples of REST API and the use of send_plugin_message which is another way that other plugins can respond to information on the UI side.

1 Like
6

All the data I like to provide to others is available in the backend and still in the frontend. So would it be helpful (or aligned with OctoPrint Guidelines) to also provide some JavaScript functions in my view model that can be called by others in addition to my python functions?

So in the backend other plugins can register itself and at the end decide to request information in python or simple call a function in my JavaScript view model...

7

It's up to you. I think there is no official guideline for JavaScript-ViewModel-Sharing.

IMHO you shouldn't implement stuff that is not needed, because each time you need to change something in the viewModel you need to make sure that the other ("unknown") consumers can handle the change. (Synced-Releases or backward compatibility)

In the past someone used (without asking) a viewmodel from one of my plugins, I did some refactoring (renaming, fixing typos,.. ) ..and a lot people were upset, because the other plugin was broken.

A compromise was not provide the viewmodel (or parts as js-function), but instead the plugin now fired "public-api-datastructures" to the browser (https://github.com/OllisGit/OctoPrint-DisplayLayerProgress#websocket).

It would be interesting to hear how other developers solves this requirement.

8

Yeah, I think the websocket approach for other plugins to get shared data makes the most sense. I've only ever used other plugin viewModels js functions to verify if the plugin was installed and enabled in order to react differently in the UI.

9

Work finished...if somebody like to comment the documentation feel free. I would be happy to get feedback. Decided that every plugin should implement its view interface which would avoid issues with undocumented calls.

1 Like