Re: Proposal: Web Services API

[Erik Huelsmann <..hidden..>]

Hi John,

> 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:

[...]

> 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.

It seems Hugh wants to take on the effort. But before we go there, I'd
say that we'd have to define the interfaces which he'll code. After
all, everybody has his own language of preference on the client side
and coding against a target spec is much easier than achieving
something without a plan.

The bit that we can do initially - as per your proposal - would be to
write the interface to the customer/vendor system. That system
supports several notions: 'entity', 'company' and 'person'. This is
currently not exposed in the web UI, but we probably should support it
from the web API, or allow future extension that way.

One of the logical next steps would probably be to find out how
exactly the entity/company/person system works and to assign
namespaces to them. With the entity API in place, we can extend the
API to customers and vendors.


Thanks for the description below to explain the kind of api you'd
expect. I think we should create schema files for the XML we accept
through the api if the body is of type application/xml?

Bye,


Erik.

> 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
>
>
> ------------------------------------------------------------------------------
> 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
>