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. Stephen _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
