They both have their place. WebDav is an established standard, by implementing it you are collaborating with all the other implementations that already use and are compatible with WebDav in some way. You join a growing ecosystem of many choices and people can easily plug your software into their architecture and plug their architecture into your software with an absolute minimum of work on their part, potentially allowing it to become widely used. This is good.
Having a socket and API allows anyone who wants to, to collaborate with your software specifically, allowing them to be able to do things highly specific to your software, but requiring more specialized work to implement. These kind of implementations can deliver great functionality but they’re likely going to be few and far between because they are more work to develop and maintain. These are very different situations, being sought by different people with different goals.
warmaster@lemmy.world 8 hours ago
By supporting WebDav your app will instantly gain the possibility to sync with every OS and a gazillion apps. It is not the best protocol, but it’s everywhere and it’s very good when implemented well. For example, CopyParty’s WebDav implementation is blazing fast.
Afterwards, you could enhance the experience by supporting websockets so that contributors can build clients specific to your project. This will take much more time to reach the user with a usable sync app, but can potentially end up in a superior experience.