Timeline for How best do you represent a bi-directional sync in a REST api?
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 19, 2016 at 0:32 | history | tweeted | twitter.com/StackProgrammer/status/777666682684833792 | ||
| Jul 1, 2015 at 9:32 | review | Close votes | |||
| Jul 10, 2015 at 3:02 | |||||
| S Nov 21, 2013 at 8:43 | history | suggested | Ben | add tag for data sync | |
| Nov 21, 2013 at 7:08 | review | Suggested edits | |||
| S Nov 21, 2013 at 8:43 | |||||
| Jul 26, 2013 at 16:01 | answer | added | David V | timeline score: 2 | |
| May 20, 2012 at 7:11 | answer | added | laurent | timeline score: 7 | |
| Apr 19, 2012 at 9:19 | answer | added | Gary | timeline score: 20 | |
| Mar 20, 2012 at 8:53 | answer | added | Tom Clarkson | timeline score: -1 | |
| Feb 19, 2012 at 3:37 | answer | added | codingoutloud | timeline score: 6 | |
| Feb 16, 2012 at 18:26 | comment | added | Edward M Smith | I understand what you're saying - there's no good answer in the event of the sync being a "black box" - any answer properly depends on the exact nature of the Sync. I'll dig into the actual sync routine and if its easily explainable, update my question. | |
| Feb 16, 2012 at 18:07 | comment | added | Adam Crossland | @RaySaltrelli, exactly what I'm talking about. Thanks for the elaboration. | |
| Feb 16, 2012 at 17:35 | comment | added | Ray Saltrelli | I agree with @Adam. Do you know how you are going to implement your sync? How are you handling changes? Do you simply have two sets of items that you want to reconcile or do you have a log of the actions that caused the two sets to diverge since the last sync? The reason I ask is it can be tricky to detect adds and deletes (regardless of REST). If you have an object server-side and don't have it client-side, you have to ask yourself, "Did the client delete it or did the server create it?" Only when you know precisely how the "resource" behaves can you accurately represent it in REST. | |
| Feb 16, 2012 at 17:21 | comment | added | Edward M Smith | That potentially exposes useful results: GET /todo_synchronizations/1 => {"todos":["/todo/1/","/todo_services/abc123/1"],"schedule":"now","ran_at":"datetime","result":"success"} | |
| Feb 16, 2012 at 17:20 | comment | added | Adam Crossland | We still have a cart-before-the-horse issue. My point was that you can't assume the sync just works and design the API. The design of the API will be driven by numerous concerns of exactly how the sync algorithm works. | |
| Feb 16, 2012 at 17:16 | comment | added | Edward M Smith | Right - assume the sync algorithm is designed and functional in the "code-level" API - how do I expose this through REST. One way sync seems much more easy to express: I GET /todo/1/ and POST it to /todo_services/abc123/ But, the 2 way - I'm not taking a dataset and PUTting it to a resource, the action I'm taking actually results in the potential modification of two resources. I guess I could fall back on having "todo syncronizations" being resources themselves POST /todo_synchronizations/ {"todos":["/todo/1/","/todo_services/abc123/1"],"schedule":"now"} | |
| Feb 16, 2012 at 17:06 | comment | added | Adam Crossland | I think that a good API design is absolutely dependent on a very concrete understanding of what you mean by sync. The "sync" of two data sources is usually a very complex problem that is very easy to oversimplify but very difficult to think through in all of its implications. Make it a "bi-directional" sync, and suddenly the difficulty is much higher. Start by thinking through the very difficult questions that come up. | |
| Feb 16, 2012 at 16:16 | history | asked | Edward M Smith | CC BY-SA 3.0 |