[PATCH v5 00/10] REST API support

Finucane, Stephen stephen.finucane at intel.com
Tue Jun 14 18:18:04 AEST 2016

On 09 Jun 17:08, Andy Doan wrote:
> On 06/02/2016 09:26 AM, Finucane, Stephen wrote:
> >On 26 May 20:12, Andy Doan wrote:
> >>This patchset is inspired by the work done by Damien Lespiau. It creates
> >>a REST API based on the original spec RFC'd by Stephen Finucane. The
> >>only thing I know of that's missing from the patch set are bundles. I
> >>think over time the Series support will make them less important, but we
> >>could always tack bundles on to this if needed.
> >>
> >>Changes since v4:
> >>
> >>* checks - include user URL rather than name
> >>* user endpoint renamed to users
> >>* user now includes more fields
> >>* expose user as URL in person endpoint
> >>* render tags when viewing a patch (and add test to validate)
> >
> >Think we're pretty much done. Most of my comments on this series
> >are about renaming fields (mostly adding '_url' to URLs) or excluding
> >them. Fix these (or ask me to fix them) and I think we can merge.
> I can spin up another patchset. Some of the changes are probably
> enough to make it useful (for example the User patch should come
> before the Person patch to address one of you concerns).

Sounds fair.

> As per _url stuff. I can do it, but I'm not sure that's what we want
> to do. This will sort of fight against the built-in support of the
> HyperlinkedModelSerializer. We'll basically have to override the
> to_representation methods of each serializer to rename "foo" fields
> to "foo_url". That's why I'd originally left out the _url fileds.
> Let me know, and I'll get a v6 sent out as soon as I can.

I still think there's real value in the '_url' suffix from an end user
POV. This sound like something we could override globally via
subclassing of the HyperlinkedModelSerializer? If this is possible, I
think it's worth doing: the output shown to the user should take focus
over reducing LOC needed to implement it, IMO. If, on the other hand,
this really does require overriding to_representation in all cases, the
sheer volume of boilerplate might make this a little less worthwhile.
Let me know sure...as the person implementing all of this, I'll go with
what you decide.


More information about the Patchwork mailing list