Attention @Developers

[Mario]

I'm currently rolling out Stage 3 of the IMWS API. This includes new endpoints for modifying database contents and structures.
Stage 3 includes some refactoring for existing endpoints - based on what I have learned from user and developer feedback over the past months.

Under certain conditions, these may cause changes in behavior or responses of some endpoints. Not substantial enough to require introduction of v2/ versions of these endpoints, more like "if you don't specify a folder id, IMWS no longer returns all folder". Maybe some streamlining / unification of response codes. Things like that.

I don't think you will need to change anything in your apps, and even if, it will cost you probably a minute or two.

As expected, it is quite challenging to implement features like adding, removing, renaming or scanning folders. Concurrency issues. Timing issues (a browser only waits for so long...). I will need to setup a completely new thread pool inside IMWS to manage long-running operations triggered by apps. Including features to monitor the progress of the operation. Tricky. Will take several releases to implement fully.

The goal is to enhance IMWS in the end to cover the full functionality of the IMatch engine (and some currently managed by IMatch).

[sinus]

I don't think you will need to change anything in your apps, and even if, it will cost you probably a minute or two.

Phew, I hope so. I have only one app, what I nee really (the attribute-app from Thorsten), but I am just at the point to definitively change to IMatch 2017. 

[Jingo]

Thx Mario - so long as the changed endpoints are documented in the release notes - we'll be all set to make modifications as needed.

[Mario]

Sure. I have fleshed out the docs in several areas. But so far no breaking changes for existing endpoints. Except that calling /folders without an id no longer returns all folders in the database. I consider this minor.