On Mon, May 21, 2012 at 12:47 PM, John Locke <[email protected]> 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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
