# A versioned API for client side plugins **URL:** \ **Category:** Development\ **Tags:** rest-api\ **Created:** [February 23, 2016, 7:20pm UTC](https://meta.discourse.org/t/a-versioned-api-for-client-side-plugins/40051 "2016-02-23T19:20:31Z")\ **Posts on this page:** 1\ **Showing post:** 16
**Author:** ![eviltrout](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/eviltrout/32/5275_2.png) [@eviltrout](https://meta.discourse.org/u/eviltrout)\ **Post date:** [February 24, 2016, 4:53pm UTC](https://meta.discourse.org/t/a-versioned-api-for-client-side-plugins/40051/16 "2016-02-24T16:53:08Z")
> [@fantasticfears](#): > > Right after the reading, it’s hard to understand the version “0.1” here. It’s not connected with Discourse version. Why? It just sounds wrong… It is the version of the API you coded against, not Discourse. This distinction allows Discourse to provide an API object that is backwards compatible. For example, you might be on a much later version of Discourse, but it can say, oh you wanted version 0.2 of the plugin API? I can build an object that responds the same way even though my internal APIs have changed. > [@fantasticfears](#): > > Can we have a nice site\_setting helper? What were you thinking? `api.siteSettings`? > [@Mittineague](#): > > this change only affects plugins that have an “initialize” ? Not exactly. It’s for client side plugins, that are written in Javascript. For example if you wrote a server side auth plugin, it won’t be affected. Having said that, _most_ client side plugins have an `initialize` function. If not, how would stuff be wired up? > [@Mittineague](#): > > if a plugin needed to be changed to comply, there would be a Deprecation in the Ember Inspector ? All the deprecations will show up in the dev console. I’m actually not sure how the Ember console works but I believe it’s meant only for Ember deprecations so they shouldn’t show up there. > [@ccdw](#): > > I do appreciate that code injected client side via the Admin panel isn’t your focus right now… could show how the following deprecated event (or equivalent) is now being generated and how we should hook into it. I just tried your snippet and it still seems to work on the latest build of Discourse. Long term I do want to allow some customizations built that way, but I have to get around to it. > [@ccdw](#): > > Is the new virtual DOM architecture limited to topics only, or are there plans to expands its use elsewhere? It’s only topics for now. There are some other parts of Discourse that render slowly that we might visit later, but there’s still a lot of work to do before that happens. My feeling is writing widgets for the virtual dom is quite a bit more complicated so you have to really want the performance benefit to take the tradeoff. > [@cpradio](#): > > How much more difficult would it be to extend that further to let Plugins denote what version(s) of Discourse they are compatible with? This is trickier than it sounds. For example, let’s say a plugin says it supports 1.3 of Discourse. Is it assumed that it will work with any later version? Because down the road we will certainly deprecate and change some APIs as we build new features. It’s good for the lower versions though – if you say it requires 1.3 it just wouldn’t load at all on 1.2. --- _[View the full topic](https://meta.discourse.org/t/a-versioned-api-for-client-side-plugins/40051)._