For me, this was the logical technology to use because it was an easier and more logical transition from my serverside roots.
But, from now on, all new projects are going to start using the REST APIs.
Why make this transition? and why write a short blog about it? Well, the last two projects I have worked on have driven me to the point of despair. They have been VERY heavy client side projects with a lot of customisations, including custom navigation components from the Term Store, aggregating content, etc.
What has driven me the most insane is managing the loading of SP.JS. This component is loaded “on-demand” as needed because it’s a very heavy file. MDS causes it to not always load and the Publishing Framework seems to be a pain as well. In fact, I cannot guarantee that it loads each time I click a link and many hours have been wasted simply ensuring these files load consistently.
So, moving forward, my companies approach will be REST based technologies.
There are other reasons that this is beneficial alongside my gripe above, such as
- It is a more industry standard technology
- It is more inline with “future” MS technologies such as Office 365 APIs and the Universal API
So… That is my epiphany and I am sure it will take some time to get comfortable with the new approach, but I think the long term benefits are worth it.
Not “quite” the same topic, I highly recommend watching Marc Andersons session from Collab365 on moving from SOAP to REST.