Re: Web services revisited

[Chris Travers <..hidden..>]

On Mon, May 21, 2012 at 12:47 PM, John Locke <..hidden..> wrote:
> Hi, Chris,
>
> Really excited to see this, looks right on target.
>
> I think the next steps might be to provide slightly more documentation
> on what's expected to be in the hashref coming out of the format handler
> and passed into the resource controller -- any standards we can define
> for those will probably help when it comes to implementing them.

The spec above would cover the general aspects.  The payload hashref
would be resource controller-specific.  For example for a customer we
might have

{ company => { id, legal_name, (country_id || country_name ||
country_code), sic, tax_id, ....,
                       notes => [{....}]
  credit_accounts => [{ id, meta_number, terms, discount_terms, ...,
                             locations => [{ location_class, line_one,
line_two, line_three, city, state, mail_code,
                                                 (country_id ||
country_name || country_code)]
                             contact_info => [{ contact_class,
description, contact}]
                             bank_accounts => [{ .... }]
                             notes => [{....}]


(As a side note in response to Tone-Irene's post above, I think this
example should show why web services are helpful here.... and why
simple API's will break down when trying to import customers.)
>
> And another non-essential comment but implementation recommendation: I
> would suggest auto-detecting the input format from its Content-type
> header, but allow a query or extension on the URL to set the output
> format -- e.g. make it so these steps are handled separately -- you can
> get an XML or JSON return from an application/x-www-form-urlencoded or
> multipart/form-data post. This can make debugging/testing much easier...

Sounds good.  I will look at doing this.

Best Wishes,
Chris Travers