Re: Flattening model relationships (in APIs)

2017-02-27 Thread marcin . j . nowak
Wanna read something interesting? Look at http://t-code.pl/blog/2016/02/rest-misconceptions-0/ You will realize how many "antipatterns" are propagated in turorials on our World Wide Web, and where they're already implemented. On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur

Re: Flattening model relationships (in APIs)

2017-02-27 Thread marcin . j . nowak
On Monday, February 27, 2017 at 3:38:34 PM UTC+1, Xavier Ordoquy wrote: > > > The more strict RESTfull way would be to use the several entry points and > use hyperlinks on them (though it would add some extra requests). > > This is just about representation. Nobody forces you to do such things.

Re: Flattening model relationships (in APIs)

2017-02-27 Thread marcin . j . nowak
On Monday, February 27, 2017 at 3:30:11 PM UTC+1, Ankush Thakur wrote: > > 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

Re: Flattening model relationships (in APIs)

2017-02-27 Thread Xavier Ordoquy
Quick question. How will you handle the fields updates ? Like, what if you get an city_name="Bombay" and city_code="DEL" ? If you can set them as read-only, then using the source argument is the way to go. Alternatively, you can define a non model serializer and flatten the data before hand.

Re: Flattening model relationships (in APIs)

2017-02-27 Thread Ankush Thakur
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,

Re: Flattening model relationships (in APIs)

2017-02-27 Thread marcin . j . nowak
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

Re: Flattening model relationships (in APIs)

2017-02-27 Thread Ankush Thakur
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,

Re: Flattening model relationships (in APIs)

2017-02-27 Thread marcin . j . nowak
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

Re: Flattening model relationships (in APIs)

2017-02-27 Thread Ankush Thakur
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

Re: Flattening model relationships (in APIs)

2017-02-26 Thread marcin . j . nowak
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? >

Re: Flattening model relationships (in APIs)

2017-02-23 Thread Melvyn Sopacua
On Wednesday 22 February 2017 00:39:42 Ankush Thakur wrote: > I'm using DRF for an API. My problem is that I defined my postal > address like this (breaking it up into City, State, Country): ... > So there's a hell lot of nesting from city to state to country. If the > relationship chain was

Re: Flattening model relationships (in APIs)

2017-02-23 Thread Ankush Thakur
Hey Mike, Thanks for your thoughts. Perhaps I presented my requirement incorrectly. I don't at all want to denormalize the database. My point was that because of the way models are related, I'm ending up with city containing state containing country. This, I feel, would be a chore for the

Re: Flattening model relationships (in APIs)

2017-02-23 Thread Ankush Thakur
Also, I don't have any need of providing several types of addresses as of now. For now I'm just sticking with outputting everything when the address is requested. ~~ Ankush On Thursday, February 23, 2017 at 9:13:01 PM UTC+5:30, Ankush Thakur wrote: > > Hey Mike, > > Thanks for your thoughts.

Re: Flattening model relationships (in APIs)

2017-02-21 Thread Mike Dewhirst
Ankush I think you might have to provide more than one method for retrieving an address so applications can request particular subsets. Perhaps a local-postal address, international-postal address, geo-location, what-three-words address and of course the full bucket as required. I think it

Flattening model relationships (in APIs)

2017-02-21 Thread Ankush Thakur
I'm using DRF for an API. My problem is that I defined my postal address like this (breaking it up into City, State, Country): class Country(models.Model): class Meta: db_table = 'countries' name = models.TextField() code = models.TextField(unique=True) class