API versioning
Question asked by Webio - 12/18/2023 at 12:02 PM

I'm not sure why previous topic has been removed since it was more general one istead of beta only.

SO: Scenario:

MSPControl provider which worked just fine for .NET Framework latest stable version is not working for latest stable .NET Core version.

Documentation for API:

does not contain aby updates regarding what has been changed. Can someone from ST propose solution how we can handle this situation?

Some time ago when legacy API stopped working for some release I could not wait for fix and created new provider which I've called SmarterMail8580 and now it makes me wonder: should I create new provider for each change which was introduced to SM API? Since there is no information in API documentation what has been changed I need to create each time provider stop working new provider for MSPControl and perform all debugging to find out what has been modified and implement those changes under new provider.

Seriously we need some discussion here because I really feel lack of interst from ST here.

Do you know why legacy API is great? Because it allows to make basic operations on domains, mailboxes, groups etc and don't need to be changed. If something NEEDED to be added to legacy API then it was introduced in new method (so we can call it some kind of API method versioning). IMHO 95% of API usage is basic operations performed by hosting control panels and since new API is also being used by SmarterMail Web GUI this makes it much much more complex for hosting control panel providers to keep up right? Previously legacy API was used only for API access, current API is used by web GUI so it will be changed waaaaaay more frequently.

Maybe having separate API section for basic operations on all items used by hosting control panels would solve this issue:

  1. New API authentication method so you can propose dropping support for legacy API offcially
  2. Simple methods with only needed params
  3. Since it will be not connected to web GUI there will be no need to update this API methods at all
So this section would be some kind of legacy API upgrade to new connection method and authentication while keeping it stable form.

Any thoughts on that from community and ST?


6 Replies

Reply to Thread
Tony Scholz Replied
Employee Post
Hello, One of the tags was closed associated with the old thread. I have removed that tag and the thread is active. 

Tony Scholz System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com
Webio Replied
Not much to add. Just like I've suggested. Issue here is that API is directly connected to current user web GUI. This makes methods a lot more complex and needed to be updated often when GUI is being changed. That's why legacy API was (and still is) working just fine for very long time for all basic hosting control panel needs where only few params needs to be passed.
echoDreamz Replied
Yeah, would be awesome to have a "simpler" API to do basic management like the older API had.
Bruce Replied
I agree that this issue requires attention. We are facing difficulties upgrading SmarterMail for the second time this year. The control panel is unable to communicate with the latest version of the software, which is due to changes in the API in SmarterMail.

It is necessary to have a set of fundamental API methods that can be used by control panels to carry out basic tasks such as generating mail domains, mailboxes, mail aliases, mailing lists and DKIM. These API methods should remain stable, and if any changes are made, they should be announced and well-documented.
Jack. Replied

Build 8755 (Dec 21, 2023)

Fixed: API documentation doesn’t properly flag obsolete methods.

Grady Werner Replied
Employee Post
The signatures of legacy apis shouldn’t change. If you find some that are breaking please let us know. There was some betas where the namespaces were broken, but those were resolved late in the beta. 

Your other comments have been noted by us for discussion here.  
Grady Werner SmarterTools Inc. www.smartertools.com

Reply to Thread