On Wed, May 23, 2012 at 7:59 AM, John Locke wrote:
> On 05/22/2012 07:06 PM, Chris Travers wrote:
>> On Tue, May 22, 2012 at 12:27 PM, John Locke wrote:
>>
>>> Possible Index handler:
>>> GET /rest/1.0/my_company/ar_transactions/?invoice_id=N499216
>> I had a thought about this one. Suppose we a
On 05/22/2012 07:06 PM, Chris Travers wrote:
> On Tue, May 22, 2012 at 12:27 PM, John Locke wrote:
>
>> Possible Index handler:
>> GET /rest/1.0/my_company/ar_transactions/?invoice_id=N499216
> I had a thought about this one. Suppose we allow a by= field to
> specify a non-standard id key? In th
Hi,
On 05/22/2012 05:10 PM, Chris Travers wrote:
On Tue, May 22, 2012 at 12:27 PM, John Locke wrote:
Hi, Chris,
One forgotten method, on the object controllers, realized on IRC:
... We need an INDEX handler.
GET would presumably get an individual resource, using an internal id
guaranteed to
On Tue, May 22, 2012 at 12:27 PM, John Locke wrote:
> Possible Index handler:
> GET /rest/1.0/my_company/ar_transactions/?invoice_id=N499216
I had a thought about this one. Suppose we allow a by= field to
specify a non-standard id key? In that case, your URL would look like
GET /rest/1.0/my_c
On Tue, May 22, 2012 at 12:27 PM, John Locke wrote:
> Hi, Chris,
>
> One forgotten method, on the object controllers, realized on IRC:
>
> ... We need an INDEX handler.
>
> GET would presumably get an individual resource, using an internal id
> guaranteed to be unique. Index would return a collect
Hi, Chris,
One forgotten method, on the object controllers, realized on IRC:
On 05/21/2012 04:44 AM, Chris Travers wrote:
> Each top-level class would need to provide the following methods:
>
> * GET, POST, DELETE, and PUT would handle cases where no resourcetype
> is present. Typically this wou
> "Chris" == Chris Travers writes:
Chris> actually look at examples, it is clear that this *is* simpler. In
Chris> your proposal we have something like:
Chris> ledgersmb?a=get_customer&id=23&format=xml&company=mycompany
Chris> The same would be a GET request to:
Chris>
> "Chris" == Chris Travers writes:
Chris> Hi all;
Chris> I am just about to start on a web services wrapper for 1.4.
Chris> Reviewing the past discussions on this, I want to just submit my
Chris> proposal for review before I get started. What I expect to start on
Chris>
Subject: Re: [Ledger-smb-devel] Web services revisited
I have to say I agree with both of you.
Chris' point is valid. There will be a steeper learning curve but the final
result will be much cleaner and easier to use.
However, Tone-Irene has an excellent point and one that I can really
I have to say I agree with both of you.
Chris' point is valid. There will be a steeper learning curve but the
final result will be much cleaner and easier to use.
However, Tone-Irene has an excellent point and one that I can really
feel for (having written at least a partial bridge between Le
Hi!
did you find the instructions in INSTALL? There the dependencies are
listed. Also, multiple people have descriptions published on the web which
steps they went trough.
Maybe we can help you through orc or this list in order to create the
desired documentation for others to follow?
Which debia
Hi..Yes Chris i get your point, but ive yet to find a manual to install ledgersmb probably on debian on the website. All the documentation is outdated and from old versions. Im afraid that this will happen with this api also, if you have no documentation it will hard for people to understand.On a s
On Mon, May 21, 2012 at 4:50 AM, Tone-irene Andersen
wrote:
> Hi..
>
> I think it would be easier to just have a one file api and not so many urls
> to take care for.
>
> Example: ledgersmb?a=poi&args
>
> where a describe the function. also possible to allow sub commands.
One thing to keep in min
Anyway, I have a brief example of a customer that's also a vendor to
be used for testing. I haven't added the tag yet. Here's
the XML:
I am thinking about using XML::Simple for this.
What do people think?
Best Wishes,
Chris Travers
---
In implementing the request handler, I made one change to the above.
from_input and to_output are only required where there is a payload.
Where there is no payload these are not called or required. This
allows there to be input or output only formats. The obvious case
would be something like a P
On Mon, May 21, 2012 at 12:47 PM, John Locke 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 resour
On Mon, May 21, 2012 at 2:46 PM, Erik Huelsmann wrote:
> Hi Chris,
>
> Looks very sane, but I agree with John: it would be nice to add some
> documentation. Maybe relate your proposal to one or two specific use-cases?
> (One that I'm thinking about is: entities/companies/persons, their eca's and
>
Hi Chris,
Looks very sane, but I agree with John: it would be nice to add some
documentation. Maybe relate your proposal to one or two specific use-cases?
(One that I'm thinking about is: entities/companies/persons, their eca's
and their related data. How would that be structured?
Bye,
Erik.
On
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 pr
Hi..I think it would be easier to just have a one file api and not so many urls to take care for.Example: ledgersmb?a=poi&argswhere a describe the function. also possible to allow sub commands.If you make something that hard your gonna have a system that noone of the "simple" people can use in the
Hi all;
I am just about to start on a web services wrapper for 1.4.
Reviewing the past discussions on this, I want to just submit my
proposal for review before I get started. What I expect to start on
is very simple.
URL would be of the format of:
[lsmb_base_url]/rest/company_name/[major vers
21 matches
Mail list logo
