On Sat, 23 Feb 2013, Kohsuke Kawaguchi wrote: > Thanks for your thoughts. > > I actually think the abstraction behind how we expose data via JSON is > fundamentally sane --- it's basically the same object graph that the server > has, > > I think the problem you are seeing is that the default behavior of > "traverse this graph depth-first to the depth 1" isn't particularly useful. > Instead, you should use the tree parameter to select what portions of the > object graph you want to retrieve. > > I've been meaning to add the object graph navigator, and I think something > like that makes it clearer what the underlying data model is.
Kohsuke and I spent a good deal of time talking in-person about this while we
were at SCaLE11x this past weekend in LA.
We've got a bit of a disagreement on how "suitable" the current API support is
for building a JavaScript application atop Jenkins might be (for the record, I
maintain that it is /not/ suitable :-P).
Kohsuke brought up a good point about plugins, not regarding extending of the
view, but rather how plugins would be plugging data into model objects such as
"Build" or "Job" for the API. I'm not entirely certain the right direction on
this, I'm hoping to find a good middle ground between the current API approach
of plugins mixing data directly into models and providing their own API
end-points separately which could lead to a plethora of HTTP requests from the
UI app.
I think the next step for my experimenting, which I'll have some time for next
weekend, will be to sketch out what I think would be most suitable for an API
after conferring with some of the guys I work with (this is literally what my
team does).
I'll update this thread once I have something on GitHub worth taking a gander
at.
Cheers
- R. Tyler Croy
--------------------------------------
Code: https://github.com/rtyler
Chatter: https://twitter.com/agentdero
signature.asc
Description: Digital signature
