|
|
| (37 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | Web app that exposes a RESTful endpoint over the [[CardSync]] core service.
| |
| | | | |
| − | === Version ===
| |
| − | [[org.eclipse.higgins.cardsync.web]] is being developed as part of [[Higgins 1.1]].
| |
| − |
| |
| − | === Used By ===
| |
| − | * This API will be first used by the [[GTK Selector 1.1-Win]] solution
| |
| − | * Specifically, this API is consumed by the synchronizing card store that is described here: [[Selector Architecture Harmonization]].
| |
| − |
| |
| − | === Requirements ===
| |
| − | CardSync must:
| |
| − | # Support a RESTful interface (not SOAP)
| |
| − | # Only use protocols and technologies that are available royalty-free, are well documented
| |
| − | # Support selectors that support N>1 cardstores
| |
| − | # Allow a selector to work completely offline
| |
| − | # Support bi-directional synchronization of individual cards and individual metadata entries about these cards
| |
| − | # Support strong authentication from client to CardSync server
| |
| − |
| |
| − | === Open Issues ===
| |
| − | # Why don't we base our design on SyncML?
| |
| − |
| |
| − | === RESTful API ===
| |
| − | * [[CardSync JAX-RS API]] - RESTful API
| |
| − | * [[CardSync Authentication]] - RESTful API Authentication
| |
| − | * [[CardSync Exceptions]] - coming soon
| |
| − |
| |
| − | === Data Transfer Objects ===
| |
| − | * [[CardSync Data Transfer Objects]]
| |
| − |
| |
| − | === Server component diagram===
| |
| − | [[Image:CardSyncComponentDiagram.png|800x400px]]
| |
| − |
| |
| − | === Closed Issues ===
| |
| − |
| |
| − | ==== Should we use WebDAV? ====
| |
| − | Reasons For:
| |
| − | * reduces our development effort as this protocol is designed for resource synchronization. And that's what we're doing
| |
| − | * mature, widely supported. Being used in new projects such as Mozilla Weave.
| |
| − | Reasons Against:
| |
| − | * Not RESTful. WebDAV extends the HTTP verb set. As such is deprecated by the W3C.
| |
| − | * Can interfere with web cache architectures
| |
| − | Decision:
| |
| − | * We will NOT use WebDAV
| |
| − |
| |
| − | ==== Should we use Google protocol buffers? ====
| |
| − | Reasons For:
| |
| − | * Mature
| |
| − | * High performance
| |
| − | * Good libraries in both C++ and Java
| |
| − | Reasons Against:
| |
| − | * Question: Might using protobuf reduce the likelyhood of the CardSpace team collaborating with us and potentially adopting the [[CardSync Protocol]]? <-- an outcome that would increase interoperability in the industry
| |
| − | Decision:
| |
| − | * We will NOT use Google protocol buffers
| |
