On Tue, Mar 20, 2012 at 2:00 PM, herman vierendeels
wrote:
> Hello,
>
> Yet another syntax-example:
>
> http://openjpa.apache.org/jest-syntax.html
>
> I am busy building a java jest_ledgersmb example war to be deployed
> under tomcat.
>
> Anyone interested?
>
That would also be interesting. Yea
Hello,
Yet another syntax-example:
http://openjpa.apache.org/jest-syntax.html
I am busy building a java jest_ledgersmb example war to be deployed
under tomcat.
Anyone interested?
Best Wishes,
Herman
--
This SF email
Just one brief note so there are no misunderstandings:
On Mon, Nov 21, 2011 at 9:38 PM, Håvard Sørli wrote:
> On 21. nov. 2011 06:33, John Locke wrote:
> > In many ways, the web application front end is a model for other
> > applications that might call the web service -- ideally everything in
On 21. nov. 2011 06:33, John Locke wrote:
> In many ways, the web application front end is a model for other
> applications that might call the web service -- ideally everything in
> the web application should be reflected in the web service.
Yes, yes, :-))
> Well, server-to-server is certain
First, great thoughts here. I think we are fast approaching total agreement.
Lots of snips in the below bit, not marked :-)
On Mon, Nov 21, 2011 at 8:42 AM, John Locke wrote:
>
> Ah, yes, I wasn't thinking through the transaction handling over
> multiple requests.
>
> If we skip doing transacti
One other thing to clarify:
I am thinking of a rich web application client here, in addition to
whatever other remote applications might get adapted to it. As you say,
Chris, web applications using only HTTP have some serious limitations.
But with the rich Javascript frameworks we have available,
Hi,
On 11/21/2011 03:03 AM, Chris Travers wrote:
> First some general notes.
>
> One of the real headaches in web app programming is state handling.
> With a thick client, what you do is you open a connection, perform
> your operations, commit your changes, etc. and then close the
> connection whe
> "Chris" == Chris Travers writes:
Chris> That's not a bad idea.
>> On authentication, yes we can use http auth headers, but do we
>> want to explicitly require a session token, too? We're starting
>> to delve into OAuth -- which adds a layer of complexity but also
>> can
First some general notes.
One of the real headaches in web app programming is state handling.
With a thick client, what you do is you open a connection, perform
your operations, commit your changes, etc. and then close the
connection when you log off. With a web application, a single atomic
unit
I may reply to John's very detailed post later, particularly focusing
on areas where the application is limited by HTTP at the moment (and
hence some skepticism as to whether the whole application should be
exportable as web services) but for now I have three questions:
1) What is the scope we wa
On 20/11/11 23:30, Chris Travers wrote:
> I don't understand. How would auth headers (or any other HTTP headers
> other than cookie headers) supply this information?
This probably reflects my misunderstanding.
Nigel
--
Hi,
On 11/20/2011 04:24 PM, Chris Travers wrote:
> I think John's points here raise some important questions I'd like to
> raise here for further discussion:
>
> On Sun, Nov 20, 2011 at 9:30 AM, John Locke wrote:
>> On authentication, yes we can use http auth headers, but do we want to
>> explici
> "John" == John Locke writes:
John> I'm starting to like /api/ or /rest/ for the path that
John> identifies the web service. And also adding an API version
John> number to that endpoint, so that it becomes possible to change
John> the API in the future while still maintaining
I think John's points here raise some important questions I'd like to
raise here for further discussion:
On Sun, Nov 20, 2011 at 9:30 AM, John Locke wrote:
> Hi, all,
>
> Been quite swamped with work recently, sorry for the delay.
>
> Having just designed a REST API for a client, have some fresh
On Sun, Nov 20, 2011 at 8:02 AM, Nigel Titley wrote:
> Sorry for the delay in reply... been off sick, back now
>
> On 18/11/11 13:52, Chris Travers wrote:
>> Figure i will wade in here. Hopefully others will follow.
>>> 1. The base address mentioned by John was something like
>>> 'http://myledger
Hi, all,
Been quite swamped with work recently, sorry for the delay.
Having just designed a REST API for a client, have some fresh
perspective. Below...
On 11/18/2011 05:52 AM, Chris Travers wrote:
> Figure i will wade in here. Hopefully others will follow.
>
> On Sun, Nov 13, 2011 at 10:45 AM
Sorry for the delay in reply... been off sick, back now
On 18/11/11 13:52, Chris Travers wrote:
> Figure i will wade in here. Hopefully others will follow.
>> 1. The base address mentioned by John was something like
>> 'http://myledger.com/ledgersmb/store/'. However, if we assume that the
>> logi
I think we should take a close look at the WS-BPEL standard:
Web Services Business Process Execution Language (WS-BPEL)
http://en.wikipedia.org/wiki/BPEL
OASIS Web Services Business Process Execution Language (WSBPEL) TC
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
"WS-BPEL
On 18. nov. 2011 23:54, Chris Travers wrote:
>> http://myhost/ledgersmb/api/company_name/
>> http://myhost/api/company_name/
>
> That is worth discussing. What do other people think?
>
> If we want it short, what about
> http://myhost/ledgersmb/ws/company_name/
Thats ok to me, as long as we mak
On Fri, Nov 18, 2011 at 7:10 AM, Håvard Sørli wrote:
> On 18. nov. 2011 14:52, Chris Travers wrote:
>> Figure i will wade in here. Hopefully others will follow.
>> On Sun, Nov 13, 2011 at 10:45 AM, Erik Huelsmann wrote:
>
>> i don;t think that would be a problem. I don't like store though
>> bec
On Fri, Nov 18, 2011 at 04:10:59PM +0100, Håvard Sørli wrote:
> On 18. nov. 2011 14:52, Chris Travers wrote:
> > Figure i will wade in here. Hopefully others will follow.
> > On Sun, Nov 13, 2011 at 10:45 AM, Erik Huelsmann wrote:
>
> > i don;t think that would be a problem. I don't like store t
On 18. nov. 2011 14:52, Chris Travers wrote:
> Figure i will wade in here. Hopefully others will follow.
> On Sun, Nov 13, 2011 at 10:45 AM, Erik Huelsmann wrote:
> i don;t think that would be a problem. I don't like store though
> because it is pretty unclear. I would suggest a base path of:
>
Figure i will wade in here. Hopefully others will follow.
On Sun, Nov 13, 2011 at 10:45 AM, Erik Huelsmann wrote:
> Hi all,
>
> Before going into detail how to interact with resources, I think we
> need to come up with a resource (URL) naming scheme which works for
> our application. There may b
A good name for the param(response_content_type ?) to indicate to the
service what type of output we are expecting
back:html,xml,json,other...
Herman
2011/11/13 Erik Huelsmann :
> Hi all,
>
> Before going into detail how to interact with resources, I think we
> need to come up with a resource (UR
Hi all,
Before going into detail how to interact with resources, I think we
need to come up with a resource (URL) naming scheme which works for
our application. There may be some things to consider, so, I thought
I'd put out a proposal for review. From there, we could go into the
more technical de
25 matches
Mail list logo
