Re: Ledger-smb-devel Digest, Vol 58, Issue 21

[Erik Huelsmann <..hidden..>]

Hi Hugh,

Thanks for your response pointing us to existing work - and for
starting this work. I saw your work is from 2009. Did you work against
1.3 in a newer (maybe unpublished) version?

> Yes, that would be me, please.

> Two some years ago I did some preliminary work on:
> http://search.cpan.org/~hesco/LedgerSMB-API-0.04a/lib/LedgerSMB/API.pm
>
> And have experience writing RESTful interfaces using Application::REST,
> I think it is.

Do I interpret your reaction correctly if I see you volunteering to
help coding this access method? If so, that's GREAT!

You're subscribed to the digest. Do you want to be explicitly included
in the CC-list, is that what you're asking?


Anyway, I see your previous work implements a Perl (client) library
for access to LSMB. The work that John and I are thinking about is to
implement an extension (server-side) with a well defined interface for
generic web access to LSMB. With this generic (language independent)
interface, it should be easy to create a Perl client library.

Application modules which have been rewritten during the 1.3 cycle
include the 'business partner' module: the system to create
customers/vendors. This is likely to remain stable for a longer time
than - say - AR/AP, which is on the brink of being rewritten in 1.4.

How to proceed from here? One way would be to define the REST
interface specs. From there, everybody who's interested could start
contributing. A starting point could be to take it from John's
proposal. Do you have any comments (good and bad) to the proposal from
John?


Thanks again!


Bye,


Erik.

> Please include me in further discussions on this question.
>
> Thanks,
> Hugh Esco
> 678-921-8186 x21
> ..hidden..
>
> From: ..hidden..
> Subject: Ledger-smb-devel Digest, Vol 58, Issue 21
> To: ..hidden..
> Date: Tue, 25 Oct 2011 20:38:20 +0000
>
>
> Today's Topics:
>
>   8. Proposal: Web Services API (John Locke)
>
>
> ----------------------------------------------------------------------
>
> Message: 8
> Date: Tue, 25 Oct 2011 13:38:11 -0700
> From: John Locke <..hidden..>
> Subject: [Ledger-smb-devel] Proposal: Web Services API
> To: Development discussion for LedgerSMB
>        <..hidden..>
> Message-ID: <..hidden..>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> Erik and I were just chatting on IRC about web services. I recently
> updated our in-house management system to generate new invoices in LSMB,
> and it's a pain in the butt to do -- the current process looks like this:
>
> 1. Hit the Login page with username/pw, store session cookie
> 2. Post some minimal detail to is.pl - customer name/entity_credit_id,
> part numbers/qty, action=update
> 3. Parse the response, scrape all the form fields out and merge their
> values with the items we want to post -- and in 1.3 make sure to update
> form_id to get past the anti-csrf protection
> 4. Post the resulting data to is.pl with action=post
>
> ... and then if we want to also send an email, essentially repeat the
> last couple steps to send the email out to the billing address.
>
> It sounds like adding a good web service api would help this project for
> at least a few of us -- but probably help get far more wide-spread
> adoption.
>
> At Freelock, we do a substantial amount of web services work, both
> creating servers and consuming them as clients. I've come to really
> favor REST-based, resource-oriented APIs that use HTTP verbs to mean
> something. I'd like to propose building a REST interface that can
> interact with the data on the server.
>
> Is this something that Moose will get us without much work?
>
> If not, I'd be happy to contribute code to serve this purpose, if I can
> find somebody to sponsor the work. And I'll definitely provide feedback
> if anyone wants to take this on themselves.
>
>
> What I'd like to see is basically an API that has a specific URI for
> each resource. For example, an invoice #456 might be referenced at:
>
> http://myledgeraddress.com/store/invoice/456
>
> A simple GET on that address would check for authorized access, and then
> retrieve the invoice in a form requested by the client. I generally set
> up services to accept a content-type header to specify xml, json, html,
> csv, etc -- and allow it to be overridden by a parameter in the query
> string.
>
> A PUT on that address with an updated object in the body would update
> the object, again based on authorization. (I'm thinking to add payment
> to an invoice).
>
> A DELETE on that address would delete (almost certainly dis-allowed on
> this type of object).
>
> POST is used to create new objects, or do particular data-changing
> actions on an object or in the system.
>
> GET would also accept a variety of parameters, providing a built-in
> search to get a collection of objects --
>
> GET http://myledgeraddress.com/store/invoice/?eca_id=334&open=any
> GET
> http://myledgeraddress.com/store/customer/?start_date=2011-01-01&start_date_oper=gt
>
>
> For implementation, this should be pretty easy to provide some sort of
> request handler and load up the new objects that Chris has created, do
> the appropriate changes, and save. The old code is obviously much harder.
>
> Perhaps we can start with the new entities, customers and vendors that
> have already been done, and add more of the accounting objects as they
> get rewritten?
>
> Cheers,
> John Locke
> http://www.freelock.com
>
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
> End of Ledger-smb-devel Digest, Vol 58, Issue 21
> ************************************************
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>