What about 200 OK and returning a short text specifying the status of synchronization?

Many replies mentioned 304. It might be worth than 304 is intended to help the client manage the local state (e.g. cache) of a resource.

Since you're talking about sync, it all depends if your request is getting the trying to get the data (sync from server to client) or pushing some data to the server (which then respond telling you nothing changed). The former use case is a valid 304. The later is not.

Furthermore, 304 is OK if the request is a GET or HEAD, and the server returns a cache-control related header like Cache-Control, Content-Location, Date, ETag, Expires, and Vary. Otherwise, intermediate layers (proxies, ...) could not correctly deal with that request (remember 304 are really targeted at managing cache)

Ref (and links to RFCs): https://httpstatuses.com/304

The correct answer to your question really depends on the logic of your sync:

• Are you just getting the last server state timestamp/hash to know if you your client is ahead and needs to push some data? (likewise a GET or HEAD to check the server latest version of the resource).
  • In that case, 304 is perfect for no change, otherwise it's a 200 to which your client sends the data to perform the sync
• Are you sending your local client data to the server to let it deal with the potential merge, and then return the diff (empty in case of no-op), In that case, I would return :
  • a 201 for the very first sync, letting know the client this is a new resource (which might triggers some additional validation/local ref storage)
  • a 200 any other successful time, with a few fields in the body: the diff, and eventually some meta-data (depending on the business logic and use cases. Maybe a csrf token too, that kind of decorating data not directly related to the content of the sync)
  • a 409 is it's a no-op because the operation cannot be performed (users connected from 2 different clients, both trying to sync and ending with a merge conflict for the later one
  • Then there are all the common error status for no-op because of failed pre-requisites (401, 403, 400 if the body is malformed, 422 if the body is valid but with invalid data)

Finally, whenever I wonder which one I should use, I very often coming back to these 2 resources:

• httpstatuses.com (built from the team behind runscope.com, httpbin.org, requestbin.org, ... they are quite used to deal with this)
• Choosing an HTTP Status Code — Stop Making It Hard which has the best http status code flowcharts I've seen so far. Clear, useful (and with a few fun things here and there). Definitely worth going through these.

Hope this helps