Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #35320 > unrolled thread

Web services/SOA - The right way

Started byAlberto Salvati <zzzato@gmail.com>
First post2016-08-14 03:04 -0700
Last post2016-08-31 10:00 -0400
Articles 20 on this page of 41 — 8 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  Web services/SOA  - The right way Alberto Salvati <zzzato@gmail.com> - 2016-08-14 03:04 -0700
    Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-14 08:14 -0400
      Re: Web services/SOA - The right way Nigel Wade <nmw@local.domain> - 2016-08-15 17:07 +0100
        Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-15 14:49 -0400
    Re: Web services/SOA - The right way Nigel Wade <nmw@local.domain> - 2016-08-15 14:00 +0100
    Re: Web services/SOA  - The right way Eric Douglas <e.d.programmer@gmail.com> - 2016-08-15 06:26 -0700
      Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-15 14:56 -0400
    Re: Web services/SOA  - The right way Alberto Salvati <zzzato@gmail.com> - 2016-08-16 02:48 -0700
      Re: Web services/SOA  - The right way Eric Douglas <e.d.programmer@gmail.com> - 2016-08-16 06:36 -0700
        Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-16 17:06 -0400
          Re: Web services/SOA - The right way Eric Douglas <e.d.programmer@gmail.com> - 2016-08-17 05:02 -0700
            Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-17 19:30 -0400
      Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-16 16:26 -0400
        Re: Web services/SOA - The right way Lew <lewbloch@gmail.com> - 2016-08-18 15:18 -0700
          Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-18 19:19 -0400
            Re: Web services/SOA - The right way Lew <lewbloch@gmail.com> - 2016-08-19 10:39 -0700
              Re: Web services/SOA - The right way Eric Douglas <e.d.programmer@gmail.com> - 2016-08-19 10:48 -0700
                Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-19 20:16 -0400
      Re: Web services/SOA - The right way Nigel Wade <nmw@local.domain> - 2016-08-17 10:11 +0100
    Re: Web services/SOA  - The right way Alberto Salvati <zzzato@gmail.com> - 2016-08-22 00:01 -0700
      Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-22 12:05 -0400
        Re: Web services/SOA - The right way Alberto Salvati <zzzato@gmail.com> - 2016-08-23 02:17 -0700
          Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-23 19:20 -0400
        Re: Web services/SOA - The right way Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2016-08-24 06:24 +0800
          Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-23 19:17 -0400
            Re: Web services/SOA - The right way Alberto Salvati <zzzato@gmail.com> - 2016-08-24 00:15 -0700
            Re: Web services/SOA - The right way Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2016-08-24 19:47 +0800
              Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-24 20:23 -0400
                Re: Web services/SOA - The right way Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2016-08-25 19:22 +0800
                  Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-25 20:20 -0400
                    Re: Web services/SOA - The right way Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2016-08-27 07:49 +0800
                      Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-26 20:11 -0400
                        Re: Web services/SOA - The right way Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2016-08-29 10:15 +0800
                          Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-30 20:39 -0400
                          Re: Web services/SOA - The right way Lew <lewbloch@gmail.com> - 2016-08-30 22:27 -0700
                        Re: Web services/SOA - The right way Stanimir Stamenkov <s7an10@netscape.net> - 2016-08-29 05:59 +0300
                          Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-08-30 20:47 -0400
                            Re: Web services/SOA - The right way Stanimir Stamenkov <s7an10@netscape.net> - 2016-08-31 16:23 +0300
                              Re: Web services/SOA - The right way Arne Vajhøj <arne@vajhoej.dk> - 2016-09-06 21:06 -0400
                      Re: Web services/SOA - The right way Lew <lewbloch@gmail.com> - 2016-08-30 22:27 -0700
                        Re: Web services/SOA - The right way Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:00 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →


#35426 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-08-22 12:05 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<npf7s1$1k5$1@gioia.aioe.org>
In reply to#35425
On 8/22/2016 3:01 AM, Alberto Salvati wrote:
> Now, I've a (BETA!) webapp developed using netbeans that:
>
> 1) runs on Tomcat 8 2) exposes 3 different servelets with doGet
> override methods 3) uses a MySql database
>
> Also, I've a delphi xe7 application that uses this webapp via HTTP
> protocol. It sounds like a poor webapp, but I'm a newbie and on
> september I'll have a demo with a my customer. So, I need something
> to show.
>
> Next, I'll work about secure my webapp (no basic HTTP
> authentication).

A few random notes:
- plain servlets is a bit primitive but as long as the in and out data
   are simple then it will work great - with more complex data then you
   need  something that handles the low level stuff for you - either
   JAX-WS or JAX-RS - and if you need to support mobile then go for
   JAX-RS
- when enabling authentication you should switch from HTTP to HTTPS
- regarding authentication then you could use container managed
   authentication and set it to BASIC (nor FORM), but I would
   suggest that you instead use a service specific HTTP header
   and implemented the check in an abstract service base class
   or in a servlet filter

Arne

[toc] | [prev] | [next] | [standalone]


#35427 — Re: Web services/SOA - The right way

FromAlberto Salvati <zzzato@gmail.com>
Date2016-08-23 02:17 -0700
SubjectRe: Web services/SOA - The right way
Message-ID<18aa1574-02c0-45b6-b135-2a11f2a4a3b0@googlegroups.com>
In reply to#35426
>    with more complex data then you
>    need  something that handles the low level stuff for you - either
>    JAX-WS or JAX-RS - and if you need to support mobile then go for
>    JAX-RS

I've planned it. 
But now I've no time to spend about JAX-RS: too many trouble


> - when enabling authentication you should switch from HTTP to HTTPS

I know it. 


>    instead use a service specific HTTP header
>    and implemented the check in an abstract service base class
>    or in a servlet filter

Thanks for this tip. 
Could you say me some "word" that I'll use to search information on the web about it?


A.


> 
> Arne

[toc] | [prev] | [next] | [standalone]


#35430 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-08-23 19:20 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<npiln8$1bbs$2@gioia.aioe.org>
In reply to#35427
On 8/23/2016 5:17 AM, Alberto Salvati wrote:
>>    instead use a service specific HTTP header
>>    and implemented the check in an abstract service base class
>>    or in a servlet filter
>
> Thanks for this tip.
> Could you say me some "word" that I'll use to search information on the web about it?

java rest custom http header

would probably be a good google term.

Arne

[toc] | [prev] | [next] | [standalone]


#35428 — Re: Web services/SOA - The right way

FromRichard Maher <maher_rjSPAMLESS@hotmail.com>
Date2016-08-24 06:24 +0800
SubjectRe: Web services/SOA - The right way
Message-ID<npiifg$1791$1@gioia.aioe.org>
In reply to#35426
On 23-Aug-16 12:05 AM, Arne Vajhøj wrote:
>   JAX-WS or JAX-RS - and if you need to support mobile then go for
>   JAX-RS
>
> Arne
>
>

Why is mobile relevant? Why does the server-tool choice dictate/restrict 
the client?

JSON in JSON out; what is JAVA trying to do?

[toc] | [prev] | [next] | [standalone]


#35429 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-08-23 19:17 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<npilhr$1bbs$1@gioia.aioe.org>
In reply to#35428
On 8/23/2016 6:24 PM, Richard Maher wrote:
> On 23-Aug-16 12:05 AM, Arne Vajhøj wrote:
>>   JAX-WS or JAX-RS - and if you need to support mobile then go for
>>   JAX-RS
>
> Why is mobile relevant? Why does the server-tool choice dictate/restrict
> the client?
>
> JSON in JSON out; what is JAVA trying to do?

It is the other way around. The client is "strongly suggesting"
to the server.

JAX-WS is SOAP XML.

JAX-RS is RESTFul JSON (or simple XML).

If you are integrating with an ESB in the 100K$ per CPU license
class then they love contract first WSDL and SOAP with lots of
extra WS-* standards.

If you are integrating with mobile then SOAP will waste
bandwidth and the developers will revolt due to poor
tool support. RESTFul JSON (or simple XML) is the only
good choice.

Arne

[toc] | [prev] | [next] | [standalone]


#35431 — Re: Web services/SOA - The right way

FromAlberto Salvati <zzzato@gmail.com>
Date2016-08-24 00:15 -0700
SubjectRe: Web services/SOA - The right way
Message-ID<d11a9710-9026-467b-b716-82b84462f991@googlegroups.com>
In reply to#35429
> If you are integrating with mobile then SOAP will waste
> bandwidth and the developers will revolt due to poor
> tool support. RESTFul JSON (or simple XML) is the only
> good choice.

I Agree. 

A.

[toc] | [prev] | [next] | [standalone]


#35432 — Re: Web services/SOA - The right way

FromRichard Maher <maher_rjSPAMLESS@hotmail.com>
Date2016-08-24 19:47 +0800
SubjectRe: Web services/SOA - The right way
Message-ID<npk1g6$16ga$1@gioia.aioe.org>
In reply to#35429
On 24-Aug-16 7:17 AM, Arne Vajhøj wrote:
> On 8/23/2016 6:24 PM, Richard Maher wrote:
>> On 23-Aug-16 12:05 AM, Arne Vajhøj wrote:
>>>   JAX-WS or JAX-RS - and if you need to support mobile then go for
>>>   JAX-RS
>>
>> Why is mobile relevant? Why does the server-tool choice dictate/restrict
>> the client?
>>
>> JSON in JSON out; what is JAVA trying to do?
>
> It is the other way around. The client is "strongly suggesting"
> to the server.
>
> JAX-WS is SOAP XML.
>
> JAX-RS is RESTFul JSON (or simple XML).
>
> If you are integrating with an ESB in the 100K$ per CPU license
> class then they love contract first WSDL and SOAP with lots of
> extra WS-* standards.

If your Aunt had balls she'd be your Uncle.

The Jury's been and gone; the verdict is REST.

What, if anything, takes the place of WS-Transaction et al is yet to be 
seen. A return to the two-pipe model such as TIP may be a good idea.

>
> If you are integrating with mobile then SOAP will waste
> bandwidth and the developers will revolt due to poor
> tool support. RESTFul JSON (or simple XML) is the only
> good choice.
>
> Arne
>
>

[toc] | [prev] | [next] | [standalone]


#35447 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-08-24 20:23 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<npldph$1fkq$1@gioia.aioe.org>
In reply to#35432
On 8/24/2016 7:47 AM, Richard Maher wrote:
> On 24-Aug-16 7:17 AM, Arne Vajhøj wrote:
>> If you are integrating with an ESB in the 100K$ per CPU license
>> class then they love contract first WSDL and SOAP with lots of
>> extra WS-* standards.
>
> If your Aunt had balls she'd be your Uncle.
>
> The Jury's been and gone; the verdict is REST.

Different contexts means different choices.

There are a lot more smartphones and web browsers out there
than expensive ESB's, but that does not make those ESB's
non-existant.

> What, if anything, takes the place of WS-Transaction et al is yet to be
> seen.

Theoretical approach is that RESTful implies no need for transactions
so a need for transaction not true RESTful.

In practice I think many solutions use a compensating model
for recovery.

Arne

[toc] | [prev] | [next] | [standalone]


#35449 — Re: Web services/SOA - The right way

FromRichard Maher <maher_rjSPAMLESS@hotmail.com>
Date2016-08-25 19:22 +0800
SubjectRe: Web services/SOA - The right way
Message-ID<npmkdf$1618$1@gioia.aioe.org>
In reply to#35447
On 25-Aug-16 8:23 AM, Arne Vajhøj wrote:
>
> Theoretical approach is that RESTful implies no need for transactions
> so a need for transaction not true RESTful.

Presumably that holds true for Session State? Yet here we are.

>
> In practice I think many solutions use a compensating model
> for recovery.
>
> Arne
>

[toc] | [prev] | [next] | [standalone]


#35464 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-08-25 20:20 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<npo211$1m4c$1@gioia.aioe.org>
In reply to#35449
On 8/25/2016 7:22 AM, Richard Maher wrote:
> On 25-Aug-16 8:23 AM, Arne Vajhøj wrote:
>>
>> Theoretical approach is that RESTful implies no need for transactions
>> so a need for transaction not true RESTful.
>
> Presumably that holds true for Session State? Yet here we are.

True RESTFul services does not use session concept.

Arne

[toc] | [prev] | [next] | [standalone]


#35479 — Re: Web services/SOA - The right way

FromRichard Maher <maher_rjSPAMLESS@hotmail.com>
Date2016-08-27 07:49 +0800
SubjectRe: Web services/SOA - The right way
Message-ID<npqkhc$1v9a$1@gioia.aioe.org>
In reply to#35464
On 26-Aug-16 8:20 AM, Arne Vajhøj wrote:
> On 8/25/2016 7:22 AM, Richard Maher wrote:
>> On 25-Aug-16 8:23 AM, Arne Vajhøj wrote:
>>>
>>> Theoretical approach is that RESTful implies no need for transactions
>>> so a need for transaction not true RESTful.
>>
>> Presumably that holds true for Session State? Yet here we are.
>
> True RESTFul services does not use session concept.
>
> Arne
>
You're starting to remind me of that guy in comp.lang.javascript "There 
is no Javascript".

Pedants please move along.

[toc] | [prev] | [next] | [standalone]


#35480 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-08-26 20:11 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<npqlr8$13f$1@gioia.aioe.org>
In reply to#35479
On 8/26/2016 7:49 PM, Richard Maher wrote:
> On 26-Aug-16 8:20 AM, Arne Vajhøj wrote:
>> On 8/25/2016 7:22 AM, Richard Maher wrote:
>>> On 25-Aug-16 8:23 AM, Arne Vajhøj wrote:
>>>>
>>>> Theoretical approach is that RESTful implies no need for transactions
>>>> so a need for transaction not true RESTful.
>>>
>>> Presumably that holds true for Session State? Yet here we are.
>>
>> True RESTFul services does not use session concept.
 >
> You're starting to remind me of that guy in comp.lang.javascript "There
> is no Javascript".

Maybe.

But in this case I think I have solid ground under my feet.

Fielding's original paper that defined REST section 5.1.3 state:

<quote>
each request from client to server must contain all of the information
necessary to understand the request, and cannot take advantage of any
stored context on the server. Session state is therefore kept entirely
on the client.
</quote>

Arne

[toc] | [prev] | [next] | [standalone]


#35496 — Re: Web services/SOA - The right way

FromRichard Maher <maher_rjSPAMLESS@hotmail.com>
Date2016-08-29 10:15 +0800
SubjectRe: Web services/SOA - The right way
Message-ID<nq05rm$1lcb$1@gioia.aioe.org>
In reply to#35480
On 27-Aug-16 8:11 AM, Arne Vajhøj wrote:
> On 8/26/2016 7:49 PM, Richard Maher wrote:
>> On 26-Aug-16 8:20 AM, Arne Vajhøj wrote:
>> You're starting to remind me of that guy in comp.lang.javascript "There
>> is no Javascript".
>
> Maybe.
>
> But in this case I think I have solid ground under my feet.
>
> Fielding's original paper that defined REST section 5.1.3 state:
>
> <quote>
> each request from client to server must contain all of the information
> necessary to understand the request, and cannot take advantage of any
> stored context on the server. Session state is therefore kept entirely
> on the client.
> </quote>
>
> Arne
>
>

You must go nuts if someone uses a Dyson to Hoover-up something.

No one gives a fuck who Fielding is. William Shakespeare's Romeo and 
Juliet argues convincingly "A rose by any other name would smell as sweet".

RESTful has become synonymous with the AJAX API. What we should be 
agreeing on is stopping the wanker-laden W3C/IETF from forcing people to 
use the FETCH API and retrofitting Promises instead of callbacks 
everywhere as part of their latest revisionist crusade.

But your more interested in the CICS/DLI, COBOL, JAVA perspective :-(

[toc] | [prev] | [next] | [standalone]


#35506 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-08-30 20:39 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<nq58vf$1qqm$1@gioia.aioe.org>
In reply to#35496
On 8/28/2016 10:15 PM, Richard Maher wrote:
> On 27-Aug-16 8:11 AM, Arne Vajhøj wrote:
>> On 8/26/2016 7:49 PM, Richard Maher wrote:
>>> On 26-Aug-16 8:20 AM, Arne Vajhøj wrote:
>>> You're starting to remind me of that guy in comp.lang.javascript "There
>>> is no Javascript".
>>
>> Maybe.
>>
>> But in this case I think I have solid ground under my feet.
>>
>> Fielding's original paper that defined REST section 5.1.3 state:
>>
>> <quote>
>> each request from client to server must contain all of the information
>> necessary to understand the request, and cannot take advantage of any
>> stored context on the server. Session state is therefore kept entirely
>> on the client.
>> </quote>

> No one gives a fuck who Fielding is.

Some does.

> RESTful has become synonymous with the AJAX API.

Only among the clueless.

AJAX works fine with both RPC style and RESTFul style.

(RPC style would probably not be SOAP, but other RPC styles
exist)

Arne

[toc] | [prev] | [next] | [standalone]


#35511 — Re: Web services/SOA - The right way

FromLew <lewbloch@gmail.com>
Date2016-08-30 22:27 -0700
SubjectRe: Web services/SOA - The right way
Message-ID<70fc6f5f-d56f-4715-af50-f1d2cc07f16b@googlegroups.com>
In reply to#35496
On Sunday, August 28, 2016 at 7:15:35 PM UTC-7, Richard Maher wrote:
> On 27-Aug-16 8:11 AM, Arne Vajhøj wrote:
> > On 8/26/2016 7:49 PM, Richard Maher wrote:
> >> On 26-Aug-16 8:20 AM, Arne Vajhøj wrote:
> >> You're starting to remind me of that guy in comp.lang.javascript "There
> >> is no Javascript".
> >
> > Maybe.
> >
> > But in this case I think I have solid ground under my feet.
> >
> > Fielding's original paper that defined REST section 5.1.3 state:
> >
> > <quote>
> > each request from client to server must contain all of the information
> > necessary to understand the request, and cannot take advantage of any
> > stored context on the server. Session state is therefore kept entirely
> > on the client.
> > </quote>
> >
> > Arne
> >
> >
> 
> You must go nuts if someone uses a Dyson to Hoover-up something.
> 
> No one gives a fuck who Fielding is. William Shakespeare's Romeo and 

Troll alert.

DNFTT

[toc] | [prev] | [next] | [standalone]


#35497 — Re: Web services/SOA - The right way

FromStanimir Stamenkov <s7an10@netscape.net>
Date2016-08-29 05:59 +0300
SubjectRe: Web services/SOA - The right way
Message-ID<nq08dv$e3n$1@dont-email.me>
In reply to#35480
Fri, 26 Aug 2016 20:11:21 -0400, Arne Vajhøj:

> Fielding's original paper that defined REST section 5.1.3 state:
>
> <quote>
> each request from client to server must contain all of the 
> information
> necessary to understand the request, and cannot take advantage of any
> stored context on the server. Session state is therefore kept 
> entirely
> on the client.
> </quote> 

The relevant resource content/state is certainly always available 
when processing a request.

Resolving authentication information (f.e. from access token 
provided via header) and making that available for processing a 
request (f.e. to ensure authorization) requires another server 
state, which might not be considered part of the REST, but is almost 
always there and as such some kind of session management is present, 
though not in the sense of WS-Transaction (mentioned previously). 
Managing some kind of transaction would be done by maintaining 
(possibly internal) resource state – that is stored on the server. 
So I think people may read this too literally.

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]


#35507 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-08-30 20:47 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<nq59fa$1r9j$1@gioia.aioe.org>
In reply to#35497
On 8/28/2016 10:59 PM, Stanimir Stamenkov wrote:
> Fri, 26 Aug 2016 20:11:21 -0400, Arne Vajhøj:
>> Fielding's original paper that defined REST section 5.1.3 state:
>>
>> <quote>
>> each request from client to server must contain all of the information
>> necessary to understand the request, and cannot take advantage of any
>> stored context on the server. Session state is therefore kept entirely
>> on the client.
>> </quote>
>
> The relevant resource content/state is certainly always available when
> processing a request.
>
> Resolving authentication information (f.e. from access token provided
> via header) and making that available for processing a request (f.e. to
> ensure authorization) requires another server state, which might not be
> considered part of the REST, but is almost always there and as such some
> kind of session management is present,

Completely stateless if difficult in practice.

The RESTful client send a token as HTTP header, the RESTFul service
checks that token with somebody else.

That somebody else does not necessarily use any in memory state to
validate token.

But probably in 99.9% of cases, then it does have an in memory cache.

And if that is the case then the difference with having container
managed security check based on a session cookie also in an HTTP header
is close to zero.

But it is still not the same as using the session object to store
service related data.

>                                             though not in the sense of
> WS-Transaction (mentioned previously). Managing some kind of transaction
> would be done by maintaining (possibly internal) resource state – that
> is stored on the server. So I think people may read this too literally.

I would still think that this transaction context in a pure RESTful
setup would exist client side and not server side.

Arne

[toc] | [prev] | [next] | [standalone]


#35522 — Re: Web services/SOA - The right way

FromStanimir Stamenkov <s7an10@netscape.net>
Date2016-08-31 16:23 +0300
SubjectRe: Web services/SOA - The right way
Message-ID<nq6lo2$6ms$1@dont-email.me>
In reply to#35507
Tue, 30 Aug 2016 20:47:39 -0400, Arne Vajhøj:
> On 8/28/2016 10:59 PM, Stanimir Stamenkov wrote:
>> Fri, 26 Aug 2016 20:11:21 -0400, Arne Vajhøj:
>>
>>> Fielding's original paper that defined REST section 5.1.3 state:
>>>
>>> <quote>
>>> each request from client to server must contain all of the 
>>> information
>>> necessary to understand the request, and cannot take advantage 
>>> of any
>>> stored context on the server. Session state is therefore kept 
>>> entirely
>>> on the client.
>>> </quote>
>>
>> The relevant resource content/state is certainly always available 
>> when processing a request.
>
> Completely stateless if difficult in practice.

Stateless is an illusion – the resource itself holds/represents a 
state...

> But it is still not the same as using the session object to store 
> service related data.

though the state is not user session specific, yes.

I still think people read specifications too literally, and likely 
miss the basics.

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]


#35559 — Re: Web services/SOA - The right way

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-09-06 21:06 -0400
SubjectRe: Web services/SOA - The right way
Message-ID<nqnp7f$19ip$1@gioia.aioe.org>
In reply to#35522
On 8/31/2016 9:23 AM, Stanimir Stamenkov wrote:
> Tue, 30 Aug 2016 20:47:39 -0400, Arne Vajhøj:
>> On 8/28/2016 10:59 PM, Stanimir Stamenkov wrote:
>>> Fri, 26 Aug 2016 20:11:21 -0400, Arne Vajhøj:
>>>
>>>> Fielding's original paper that defined REST section 5.1.3 state:
>>>>
>>>> <quote>
>>>> each request from client to server must contain all of the information
>>>> necessary to understand the request, and cannot take advantage of any
>>>> stored context on the server. Session state is therefore kept entirely
>>>> on the client.
>>>> </quote>
>>>
>>> The relevant resource content/state is certainly always available
>>> when processing a request.
>>
>> Completely stateless if difficult in practice.
>
> Stateless is an illusion – the resource itself holds/represents a state...

That is sort of given by the last 2 letters in REST.

:-)

>> But it is still not the same as using the session object to store
>> service related data.
>
> though the state is not user session specific, yes.
>
> I still think people read specifications too literally, and likely miss
> the basics.

Maybe.

But this sub thread started discussing transaction context and
HTTP session.

I would definitely avoid those for RESTful service.

Arne

[toc] | [prev] | [next] | [standalone]


#35510 — Re: Web services/SOA - The right way

FromLew <lewbloch@gmail.com>
Date2016-08-30 22:27 -0700
SubjectRe: Web services/SOA - The right way
Message-ID<ebc9baa7-20fd-4ba4-8921-3bf13b2fb848@googlegroups.com>
In reply to#35479
On Friday, August 26, 2016 at 4:49:13 PM UTC-7, Richard Maher wrote:
> On 26-Aug-16 8:20 AM, Arne Vajhøj wrote:
> > On 8/25/2016 7:22 AM, Richard Maher wrote:
> >> On 25-Aug-16 8:23 AM, Arne Vajhøj wrote:
> >>>
> >>> Theoretical approach is that RESTful implies no need for transactions
> >>> so a need for transaction not true RESTful.
> >>
> >> Presumably that holds true for Session State? Yet here we are.
> >
> > True RESTFul services does not use session concept.
> >
> > Arne
> >
> You're starting to remind me of that guy in comp.lang.javascript "There 
> is no Javascript".
> 
> Pedants please move along.

You respond with insults instead of engineering.

A pedant is person who understands and respects the rules in detail. In computer programming, that's a virtue, not a sin. So in your puerile attempt to insult the person, you gave the reason to follow their advice.

-- 
Lew

[toc] | [prev] | [next] | [standalone]


Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer


csiph-web