Allow to use api to control opening notes in external editor
Support hooks function, that is, allow external monitoring of joplin operations through api (such as web socket). At least the hooks for the following operations should be included
When creating/deleting notes/directories
When modifying the metadata of a note/directory (for example, the body of the note does not count as metadata)
When modifying the label of a note
If no one wants to implement the above functions, I may start to modify the joplin desktop client to support the above API next weekend.
Currently the API is indeed only a data API, so only to get, set and delete objects. It’s easy to maintain because most end points are automatically generated - it’s simply a wrapper to the underlying data model. If someone changes something to the model, there’s nothing to change on the API, it will just work.
If we want to provide access to Joplin’s services and internal operations that’s a different story however, and probably harder to automatically generate and harder to maintain.
Yes, this makes maintenance more complicated, especially with the introduction of websockets, but I believe these APIs can expand the development of third-party tools in the joplin ecosystem.
At present, what API can do may actually be more “show” rather than “enhanced”, such as the following function
-Render a website, such as a blog, read and generate some markdown files through api, and then use an existing static blog generation tool, such as hexo, to generate a website (while having a rich ecology, including various themes and plugins), Finally deployed on github pages.
But if you can support the above APIs, I even think that you can package a program based on vscode, use vscode-joplin out of the box (including a series of plug-ins and well-modulated configuration items), and have the vscode editing function synchronized with joplin’s current And other functions.
Taking a step back, even if joplin is more functional in the future (such as reaching the level of notion), as long as it is still based on markdown, you can still edit it in vscode, because some people (such as me) do not like non-standard markdown , Because copying to other places is difficult to render correctly.
Those are good points. I’m interested in making the app more extendable so that new features can be developed as plugins or external scripts.
I’ve started a branch to add plugin support but maybe instead it should be some kind of advanced API like you describe. It gets back to the concept of x-callback-url which has been discussed in other threads, and that would allow external apps to call functions within Joplin.
Still not completely sure what’s the best approach so for now I’m just collecting ideas.
There is only one core problem at the moment - it is not possible to open notes in an external editor via api. Others are just enhancements, and you can bypass it if you don’t, so it’s not so anxious. For example, web hooks are for instant synchronization of the note directory, but you can also query the details of the note when you click on the note, and if not, refresh the note directory tree.
Yes, but the synchronization problem caused by this can be non-existent, and if the update supports the feature, it must be replaced. In short, I think I am repeating the synchronization thing-but I can also Try it first to see the effect.
That’s true, if a note is modified via sync or otherwise, the external file would be updated in Joplin, but not if it’s done by a script outside.
And even a plugin wouldn’t solve the problem in this case as it’s not something you want to add to Joplin, but a function you want to call from outside. Perhaps there’s a need for both an “action” API (as opposed to the existing data API) and plugins.
Besides the hook functions, which will be harder to implement, are there other API calls that would help support your extension? I think your project is a good use-case to experiment with Joplin extensibility.
The api header does not understand why it should be set to 'Content-Type':'application/x-www-form-urlencoded'
I'm not sure what you mean about this? All API calls accept application/json (except for POST resources) and other content-type won't work. There's more info about it in the doc: https://joplinapp.org/api
Oh, the second point is that I made a mistake. . .
In addition, there is no need for other APIs at present. The priority of hooks does not need to be so high. I will first try to update the directory tree using regular refresh + tree diff.
After the above mentioned issues are fixed, I will release v0.1.0 in the VSCode official store, and then use it for a while to talk about it (time to verify all this)