リソースを持つWebアプリケーションと、別の同様のリソースを持つリモートアプリケーションへの参照があるシステムを想定して、「ローカル」リソースを「リモート」リソースと同期する双方向同期アクションをどのように表現しますか？
例：
ToDoリストを表すAPIがあります。
GET / POST / PUT / DELETE / todos /など
そのAPIは、リモートTODOサービスを参照できます。
GET / POST / PUT / DELETE / todo_services /など
APIを介してプロキシ経由でリモートサービスから仕事を操作できます
GET / POST / PUT / DELETE / todo_services / abc123 /など
TodoのローカルセットとTODOSのリモートセット間で双方向の同期を行う機能が必要です。
ある種のRPCでは、次のことができます
POST / todo_services / abc123 / sync /
しかし、「動詞は悪い」という考えでは、このアクションを表現するより良い方法はありますか？
4
優れたAPI設計は、同期の意味を非常に具体的に理解することに絶対的に依存していると思います。通常、2つのデータソースの「同期」は非常に複雑な問題であり、単純化するのは非常に簡単ですが、その影響をすべて考慮することは非常に困難です。それを「双方向」同期にすると、突然難易度が非常に高くなります。出てくる非常に難しい質問を熟考することから始めます。
—
アダムクロスランド
正しい-同期アルゴリズムが「コードレベル」APIで設計され機能していると仮定します-これをRESTで公開するにはどうすればよいですか。一方向の同期ははるかに簡単に表現できます：私
—
エドワード・M・スミス
GET /todo/1/とPOSTそれへ/todo_services/abc123/ の2つの方法-データセットを取得してリソースにPUTするのではなく、実際に実行するアクションにより、2つのリソースが変更される可能性があります。私は、リソースそのものが「藤堂syncronizations」を有するに頼ることができると思います POST /todo_synchronizations/ {"todos":["/todo/1/","/todo_services/abc123/1"],"schedule":"now"}
私たちはまだ馬術前の問題を抱えています。私のポイントは、同期が機能することを想定してAPIを設計することはできないということです。APIの設計は、同期アルゴリズムが正確にどのように機能するかについての多くの懸念によって推進されます。
—
アダムクロスランド
これにより、有用な結果が潜在的に公開されます。
—
エドワードMスミス
GET /todo_synchronizations/1=>{"todos":["/todo/1/","/todo_services/abc123/1"],"schedule":"now","ran_at":"datetime","result":"success"}
@Adamに同意します。同期の実装方法を知っていますか？変更をどのように処理していますか？調整するアイテムのセットが2つあるだけですか、それとも最後の同期以降に2つのセットが発散したアクションのログがありますか？私が尋ねる理由は、（RESTに関係なく）追加と削除を検出するのが難しい場合があるからです。サーバー側にオブジェクトがあり、クライアント側にない場合は、「クライアントがそれを削除したのか、サーバーが作成したのか」と自問する必要があります。「リソース」の動作を正確に知っている場合にのみ、RESTでそれを正確に表すことができます。
—
レイモンドサルトレリ