Certainly there are improvements that can be made to the API (e.g. I
think there is little to no paging in general, which makes it tough to
build certain views efficiently (JENKINS-22977 is probably related)),
but as Kohsuke mentions in that thread, most of the data should be there.
So I don't think the API necessarily has to be RESTful — from what I
understand, Backbone expects data to be structured in a certain format;
other JS frameworks like AngularJS don't make this distinction.
On 05/28/2014 11:08 AM, Tom Fennelly wrote:
Thanks Tyler. I now understand what you mean about the API structure.
On Tuesday, May 27, 2014 10:46:45 PM UTC+1, R Tyler Croy wrote:
(replies inline)
On Tue, 27 May 2014, Tom Fennelly wrote:
> Did you ever commit your experiments to GitHub? I'd be keen to
see what
> you did and would also be keen to hear your thoughts on the API
and it's
> suitability. I started a related thread (wasn't aware of this
one until
> now) at
https://groups.google.com/forum/#!topic/jenkinsci-dev/zDaX4yiWLLw
<https://groups.google.com/forum/#!topic/jenkinsci-dev/zDaX4yiWLLw>
This fell off my queue of "things I have time to work on" so I never
got around
to it.
The biggest challenge to the API work IMO is that it's currently not
RESTful,
and is quite difficult to make RESTful in a way that a Backbone
collection can
easily consume from.
Part of the challenge is that Jenkins' datamodel is much more of a
tree than
most front-end toolkits are familiar with, but when you add added
functionality
from the plugins, modeling becomes extra tricky.
I'm still of the opinion that a simple Backbone app + basic REST API
exposing
jobs, builds, basic details, would be more than enough for a large
percentage
of use-cases. Putting my code where my mouth is, isn't something
I've had time
for unfortunately.
> On Monday, February 25, 2013 4:09:53 AM UTC, R Tyler Croy wrote:
> >
> >
> > 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
--
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/d/optout.
