I guess this is the library in question: https://github.com/marcinn/restosaur (took some effort to find it!). Thanks, if I decide to stick with the API-first approach, I'll use it. Either way, I've bookmarked it for future use. :-)
Regards, Ankush Thakur On Mon, Feb 27, 2017 at 7:53 PM, <[email protected]> wrote: > I was limited by DRF long days ago and I realized that it is not following > REST architecutre. It does good job in automation in exposing models over > http, but everything else is way complicated. > But there were no problem mix both tools in one project. DRF was for "80%" > of work and my lib for the rest. Downsides? Two libs used to get the job > done. > > Maybe try using DRF's @api_view decorator for function views, and return a > pure and manually "flattened" dict? > > M. > > > On Monday, February 27, 2017 at 3:17:35 PM UTC+1, Ankush Thakur wrote: >> >> Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm >> myself finding DRF too restrictive once you are past the effort-saving >> magic. Thank you. I might give it up as it's still early days in the >> project. >> >> >> Regards, >> Ankush Thakur >> >> On Mon, Feb 27, 2017 at 7:43 PM, <[email protected]> wrote: >> >>> I'm not sure you want to read my answer, really... I've finally stopped >>> using DRF and wrote own library which is focused on resources, linking and >>> representations. >>> I think you can do some customization in DRF, probably you ca declare >>> custom serializer class, but this is a hard way, IMO. >>> >>> I like simple things, so with my lib I can just do something like that: >>> >>> payments = api.resource('/payments/') >>> customer = api.resource('/customers/:pk') >>> >>> >>> @payments.representation >>> def payment_as_json(payment, ctx): >>> return { >>> 'customer_address': payment.customer.address, >>> 'customer_url': ctx.link_to(customer, pk=payment.customer_id), # >>> link resources >>> 'value': payment.value, # write here >>> 'and_so_on': True, # what do you want >>> } >>> >>> Yes, it does not validate automatically and this example is not restful, >>> but you may follow semantic structures like jsonld without any limitation, >>> and apply validation in a controller: >>> >>> @payments.post(accept='application/json') >>> def add_payment(ctx): >>> form = PaymentForm(data=ctx.body) >>> form.is_valid() and form.save(0 >>> [...] >>> >>> Where PaymentForm may be a typical Django Form or ModelForm, or even a >>> Colander Schema. >>> There is more code to write, but implementation is more explitic. >>> >>> PEP20: Explicit is better than implicit. Simple is better than complex. >>> Flat is better than nested. Readability counts. And so on... >>> >>> BR, >>> Marcin >>> >>> >>> >>> On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote: >>>> >>>> Marcin, that's exactly where I'm stuck! I know endpoints should never >>>> be 1:1 serialization of models, but I just don't know how to do that. I >>>> mean, I've been able to create endpoints like "/customers/1/payments/" >>>> where I use model relationships to generate JSON structures where Customer >>>> contains a Payments array field. My Address endpoint seems to be an oddity, >>>> as API consumers don't expect the city to contain state and the state to >>>> contain country as a JSON structure. How can I add these to the top-level >>>> Address entity directly while serialization? That's where I have no >>>> answers. Would it be possible for you to point me towards some article that >>>> does that? Thanks in advance! >>>> >>>> Regards, >>>> Ankush >>>> >>>> On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, >>>> [email protected] wrote: >>>>> >>>>> >>>>> >>>>> On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote: >>>>>> >>>>>> If the relationship chain was even deeper, there would be even more >>>>>> nesting, which I feel isn't great for API consumers. What is the best >>>>>> practice here to put state and country at the same level as the city? >>>>>> >>>>> >>>>> Just follow REST design. >>>>> Forget django models, think about encapsulation. >>>>> Think about representation of a resource, not about serializing a >>>>> model(s). >>>>> Make semantic representations, as good as possible. >>>>> >>>>> You are not forced to do any nested nasty things. This has nothing to >>>>> do with REST api. >>>>> You may feel that DRF is limiting you. You'll be on a good path, if >>>>> so. :) >>>>> >>>>> Good luck! >>>>> Marcin >>>>> >>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Django users" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>> pic/django-users/ttoJbZJOBnU/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/django-users. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/django-users/ttoJbZJOBnU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/8dbe0176-7fcd-4736-a0ba-78aee3408ac1%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/8dbe0176-7fcd-4736-a0ba-78aee3408ac1%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALX%3DrKLx31PgMUWVm6g6yT%3DH-Bgz-JfF7%3Daf2cZa-gZzgP5pjQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
