[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Web services revisited
- Subject: Re: Web services revisited
- From: John Locke <..hidden..>
- Date: Mon, 21 May 2012 12:47:43 -0700
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.
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...
On 05/21/2012 04:44 AM, Chris Travers wrote:
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 version]/[top level
"rest" would be a reserved word and not usable for any later part of
the API. I.e. it can never be a valid object name, resource type, id,
or object class name. We'd use it to automatically determine where
the path starts.
There would be two additional directories of objects here.
LedgerSMB/REST_Formats/*.pm would be to handle formats (XML, JSON,
etc). LedgerSMB/REST_Objects/*.pm would provide handling of the actual
top-level objects. LedgerSMB/REST_FORMATS/DEFAULT.pm would be
reserved for handling standard form-multipart post data. Right now it
would just throw an error.
Each format handlerwould have just two methods: from_input() and
to_output() which would encode or decode the format.....
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 would be search, retrieve, or post
* One method for each resourcetype, suffixed optionally with _GET,
_POST, _DELETE, or _PUT. If a suffixed method does not exist, the
resourcetype name would be used as the method name.
My thinking is to have the flow go as follows:
Main handler parses request, organizes it into a hashref with the
following components as applicable:
dbh (database handle)
The payload would then be handed off to the format handler and reset
as a hashref returned from the from_input routine.
The handler would then use the appropriate class, and dispatch as follows:
If resourcetype is present, try to dispatch to resourcetype_method, if
that fails dispatch to resourcetype. If resourcetype is not present,
dispatch to method.
Take hashref that is returned and hand back to the format handler for
it to be run through the to_output function, and then send this back
to the browser.
What do people think?
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
Ledger-smb-devel mailing list