RestFM – The fourth synchronization tool reviewed

We’re moving past the three best known products for Filemaker synchronization into the more recent additions,. The next three products we’ll review are not as well known, but the still have a lot to offer.

For those new to the series, we reviewed MirrorSync three weeks ago in a previous post, and two weeks ago we reviewed GoZync. Last week we presented our review of SyncDek2Go. If you want to read a bit about our testing environment and our tester you can read about it in our first post.

This time around we’re reviewing RestFMSync, which is a synchronization feature from within the RESTfm API, made by the team at Goya Ltd.

For those not familiar with the RESTfm API, well you should be. 🙂 From their website, RESTfm is:

RESTfm turns your FileMaker Server into a RESTful Web Service, so you can access your FileMaker Server databases via HTTP using a common REST architecture with easy to understand API calls.

This is a great tool, and while we love the tool and the idea in general, here we’ll just be reviewing the synchronization portion of the tool.

As with the last reviews, we’ll start with a review of the tools and it’s features from our intern Patrick.

RESTfm accesses FMS using HTTP instead of using FMP networking protocol this allows for better connectivity and speeds. It avoids having to open and close files and instead just grabs the records it needs. Also it is able to use different data formats to send data based on the circumstances. A unique feature that isn’t exactly a positive is that RESTfm does not support container field syncs as of yet, so there won’t be any container sync information on this tool.

Since this tool is so unique I wasn’t sure what to expect on the integration front. My instinct was that it was going to be the most complicated of the lot, but I was pleased to find myself wrong. While everything did not go flawlessly, it didn’t turn out to be as difficult as I feared it would. From Patrick:

This integration can be a bit cumbersome since it needs outside applications installed. To start you need to install RESTfm. That is accomplished by installing the Microsoft URL Rewrite module (if you are on a pc, macs don’t need to install anything like this). Then unzip RESTfm into the FMS webserver root directory. After getting that all squared away it then goes to creating tables, layouts, importing scripts etc. The usual sync tools affair. If you follow the guide carefully and use the sample solutions as resources integration is easy. In total it took me about an hour or hour and a half to get RESTfm integrated.

However I did run into weird errors that made it so I was unable to sync. I spent countless hours pouring over the scripts trying to find something to fix the error, as well as being in frequent contact with their support. They offered helpful advice that would fix an error but another one would just pop up after. The biggest error was telling me there was field missing even though I had copied and pasted the table exactly how it was (except for the fields specific to RESTfm). After what felt like an eternity it just magically started syncing. It just worked and I have no idea why.

Be weary about editing your files after getting to work though. After I added matching fields in both the local and hosted files they ended up not working again and I got the same error as before. Like before I waited a long time doing many different things, then out of no where it would just work.

My impression was that it is a good tool, that just needs a bit more work to be great.

With the product integrated we moved onto the sync process. Remember that container fields are not supported, so there will be no data for them. Patricks thought were very straightforward.

Pretty standard syncing with this one. It is not the fastest sync tool but it is not the slowest either. It is actually pretty comparable to GoZync in terms of it’s speed. The major difference is that RESTfm is not able to sync containers quite yet.

So on to the speed test results.

In summary RESTfmSync is in the middle of the road, not the fastest or the slowest. If they had container synchronization I would be very interested to see where it would land as that is one area there seems to be more separation in performance.

As before in choosing features to list and compare, we tried to focus on features that were quantifiable and concise, but weren’t covered in other analysis. For RESTfmSync they provide (what we consider the preferred answer is in green, the less ideal answer in red):

This one was more of a mixed bag. I want to include some of Patricks final thoughts:

I don’t know how I feel about this tool. It offered extremely consistent syncs, I knew just about when each sync would finish. The biggest deterrent is the random “Field not found” error. It might be something with my setup or with RESTfm itself. If it was not for that it would have my full endorsement. Besides that I would recommend this to people as long as they don’t need to sync containers. 

I think this is the most interesting tool reviewed so far. Relying on a REST API to get the work done is an interesting method. Give this one some time and it may be a real competitor.

As in the last reviews, we’ll we have another one coming next week. If you’d like us to expand our testing to include something you feel we may have missed, or just want to chime in with your thoughts or say something nice about RESTfmSync or Goya. Please leave a comment below.