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. 2013/2/23 R. Tyler Croy <[email protected]> > At the FOSDEM Developer Meetup, I suggested that building a better UI on > top of > Jenkins would likely be easiest by ripping the UI out of the Java layer and > going the more common API + JavaScript application approach which is > commonly > used for web applications today. > > > I spent some time experimenting with this while traveling across Europe and > here are the biggest issues I've identified: > > * The Jenkins remote API is CRAZY (not good). The data you will find on > the > /api version of a URL often times doesn't > map ot what you see on the page. > > Take the "home page" for example, whose API response has: > * Some information about executors on the master, but nothing on the > slaves > * Contains information about slave ports? > * Lists jobss that, if you have a different default view, are not the > same as the default view (not sure if this is good or bad) > > There isn't a clear "object model" being exposed for jobs, depending on > your depth, you might get a lot more information which /seems/ > relatively > haphazardly put together, instead of exposing a logical Job object > over the > API > > * To work effectively, an alternate API would *have* to run as a plugin, > to > run on the same domain to avoid needing to use the JSONP API which > would > make write operations difficult. This would make (IMHO) things a bit > tricky > for distribution/updates of the UI App. > > * Exposing plugin views is going to be a scary/difficult. Right now you > have > Jelly/Groovy views that get smattered onto the page, and in many cases > can > and *will* break the page (configuration pages, lookin' at you). I'm > looking at other examples of "JS SDKs" (e.g. <https://teambox.com/api2 > >) > for inspiration on how to make JS views/functionality more pluggable, > while > maintaining some semblance of safety, to protect the page from bad code > injected by plugins > > > My current mode of thinking (and why I asked about Groovy plugins before) > is > that what is needed is a plugin that provides a more suitable API for the > task > at hand, but also can bundle up the UI App and serve it off of Jenkins > itself. > > > Time permitting I'll be exploring that a bit more, I just wanted to let > everybody know where my head was at after some experimentation. > > > Cheers > - R. Tyler Croy > -------------------------------------- > Code: https://github.com/rtyler > Chatter: https://twitter.com/agentdero > -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
