Just a quick note -- the difference between the JSON RESTful API and the AtomPub RESTful API is fairly minimal at a high level; all the actions, URLs, and patterns are the same, and all based on AtomPub throughout (and in the batch interface, you can even mix the two). The only difference is the data format (format=json or format=atom) and there's a 1:1 mapping between the two formats so they're structurally alignd. Without getting into whether Abdera is the best starting point or not, it'd be surprising if there were not nearly 100% commonality in everything except the serialization code. These aren't two APIs; they are one API with two flavors of data.
(Very tempted to add an optional format=csv data flavor to the spec, just for fun...) On Tue, Jun 10, 2008 at 5:43 PM, David Primmer <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 3:58 PM, Cassie <[EMAIL PROTECTED]> wrote: > > As Kevin mentioned though json->pojo->json is the easiest part of all > this > > because it is already done within shindig. Our small utility class does > > everything it needs to do and no more. It isn't fancy and we could > > definitely replace it later on with something more standard, but for now > > that's all taken care of. > > > > All we really need to do for rest is write a simple servlet that maps the > > restful url patterns onto correct handlers and pulls out the url params > that > > each of the handlers need. And then we need tests. It should be super > simple > > (like maybe 2 additional classes with potential copies of the *Service > > interfaces and the OpenSocialDataHandler for now because they don't quite > > fit rest.) > > I had assumed that "all we really need to do for rest" is the same as > the OpenSocial 0.8 spec. However, the task that document outlines is a > lot longer than the one the paragraph above describes. There are a few > more aspects of that spec, including batching, partial updates, > merging auth context with request url context, paging and concurrency > control. Will all these be done twice? > > > > > This is why I think abdera was a silly choice for us - this code should > be > > dead simple and abdera was making our lives non complicated. However.. > the > > atom is more complicated than the json, so maybe it is a better fit? > > The answer depends on what your perception of "us" is, I think. How do > you plan on running the two servers concurrently, both answering the > same url patterns but one taking the requests of ?format=atom and the > other taking requests with the param ?format=json ? > > > > > - Cassie > > > > > > On Tue, Jun 10, 2008 at 3:53 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > > > >> I should have read the rest of the thread before posting, sorry. I was > >> forgetting just how big the Person object was and just how compact > >> annotations are.... and then there will be the pain of maintenance > >> with anything that large hand coded. > >> > >> We might be talking about different jsonlibs ?, > >> http://json-lib.sourceforge.net/usage.html does both ways serialize > >> and parse, based on getters and setters..... but I suspect the hand > >> coding is still a killer and mapping may be a pain, so annotations > >> still win (IMH and better informed O :) ) > >> > >> Ian > >> > >> 2008/6/10 Kevin Brown <[EMAIL PROTECTED]>: > >> > On Tue, Jun 10, 2008 at 3:12 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > >> > > >> >> I have had good experiences with trees of maps and lists containing > >> >> primitive types, serialized by json-lib. The same trees are easy to > >> >> serialize using the apache xml-rpc libraries, and appear to stack-up > >> >> reasonably well underload. Its not sophisticated, but it is fast to > >> >> work with, light on the GC under load and appears to perform well. > >> > > >> > > >> > The JSONObject library being used right now handles primitives and > >> > containers already (JSONObject.put(Map), JSONObject.put(Collection)), > as > >> > well as bean-style objects (JSONObject.put(Object)). That doesn't > handle > >> the > >> > conversion back, though, which is where a library would come in handy. > >> > > >> > This isn't just an issue for the social data, either -- the metadata > >> handler > >> > is currently doing all this by hand, and it would be much more > convenient > >> to > >> > just have an annotation processor or something along those lines. > >> > > >> > > >> >> > >> >> I was going to try abdera in another project, now I am not so sure. > >> >> > >> >> 2008/6/10 Cassie <[EMAIL PROTECTED]>: > >> >> > We tried to use abdera to implement the opensocial json restful > format > >> >> > within Shindig.. and it didn't work out very well. The code is > clunky, > >> >> > overly complicated for simple json and is hard to come up to speed > on. > >> >> > > >> >> > So... I am going to try an alternate implementation based on the > >> existing > >> >> > older json wire format code. I was going to start coding something > in > >> a > >> >> > separate dir so that none of the current code is disturbed. > Hopefully, > >> in > >> >> > the next couple days we will have a cleaner impl of the restful > json > >> that > >> >> is > >> >> > 90% the same as all of the current social code. (this means less > >> >> migration > >> >> > for current social code users too, yea!) > >> >> > > >> >> > And as for atom... well, we can figure that out later :) > >> >> > > >> >> > Please let me know if you have any huge objections to this. > >> >> > And of course, if it turns out to be worse than the abdera impl.. > we > >> can > >> >> > always go back. > >> >> > > >> >> > - Cassie > >> >> > > >> >> > >> > > >> > > >
