Re: Proposal for 2.0: SODA 2.0

[Luke <..hidden..>]

You need the ability to support multiple APIs, or at least two API layers.

One for web access.
Another for thick access.

That is where the DB abstraction layer is appealing--it allows a certain 
writing of thin API shells to interact with it.

I can't imagine that it is the only way, however.
In the normal client server model, the DB is a backend, not a part of the 
API.

That aside...

My initial thinking is that an API sufficient for thick clients should be 
primary.  The web interface should then be written as, effectively, a 
thick client which provides services to web clients.  Yes, it would be the 
primary interface, but if done right the performance hit would not be any 
worse than in the past.
I have not thought this out in great detail.

Luke



On Mon, 8 Mar 2010, Adam Thompson wrote:

> Agreeing with Chris, *WEB*-based services aren't appropriate for everything - POS being an excellent example.
> So, I disagree with making REST the common integration point.  I also don't want to use web-based APIs on, for example, handheld terminals collecting inventory information.
>
> ------Original Message------
> From: Kaare Rasmussen
> To: Development discussion for LedgerSMB
> ReplyTo: Development discussion for LedgerSMB
> Subject: Re: [Ledger-smb-devel] Proposal for 2.0: SODA 2.0
> Sent: Mar 8, 2010 12:42
>
> > I can't speak for Chris, but from my point of view, putting everything
> > in the DB is nice because it lets me use $FAVORITE_LANGUAGE to access
> > the database, where $FAVORITE_LANGUAGE may or may not be Perl.
>
> That's what REST (or webservices) are for. ISTM that you want to replace a
> perl api with an api written in a much more rigid language. I'm sure it will
> hurt developer performance (and perhaps developer enthusiasm)..