azurestandard/api-spec — pull request #2 by wking (2014-11-15 16:03:04+00:00)
Title: How should we handle person addresses?

From IRC yesterday:

14:39 < wking> hmm, we're keeping the (person|drop)<->(address)
association outside of the data structures I'm defining in the spec.
That means creating a new person address is going to look like:
'POST /address?person=123'. Or maybe 'POST /address' (returns ID),
'POST /person/{id}/address' (with an ID payload). Thoughts?
14:40 < wking> actually, drop.address is in the spec. Maybe I want to
put person.addresses in the spec?
14:41 < wking> That means you'd need 'PUT /person/{id}' to update
addresses, but that's probably fine
14:41 < shofetim> person.address != drop.address
14:42 < wking> How are the data structures different? It's just an
address, right?
14:54 < shofetim> ah yes, just that person needs one too. For billing,
mail, etc.
15:16 < wking> yeah, I think people can have an array of addresses
(e.g. previous UPS addresses) as well
15:36 < wking> hmm, maybe we need a tag for each person address type
then? person.address.billing, person.address.mail,
person.address.ups-1 ?
15:38 < wking> how do we want to keep that straight? In Beehive we
have primary_address, addresses, and sold_to_address ( which is
primary_address, but falls back to vendor.primary_contact, and falls
back again to the latest address with a 'billing address' note)
15:38 < wking> do we need an address.type field?
15:55 < shofetim> I think we can avoid an address.type field, but I
don't really know. Nice not to type things ahead of time unless they
need it (ie the mailing, billing, and drop address could be the same
for a drop co-ordinator that has the drop at their house, no need to
have them enter or save it three times)
15:58 < wking> they probably won't be writing out their API POST body
by hand ;). So API-level duplication could be handled by the UI.
15:58 < wking> maybe an optional address.type which would be a list of
uses
15:58 < wking> and person.get_address(type=mail) would iterate over
person.addresses until it hit one with 'mail' in the type array?

I'm currently leaning toward an optional person.addresses array and
adding a 'types' array to the address model, because handling
ownership of addresses that are tracked as a separate model would be
too complicated.