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

Groups > comp.programming > #3674 > unrolled thread

REST

Back to article view | Back to comp.programming

Contents

  REST bob <bob@coolfone.comze.com> - 2013-08-20 16:00 -0700
    Re: REST Jongware <jongware@no-spam.plz> - 2013-08-21 10:15 +0200
    Re: REST JJ <duh@nah.meh> - 2013-08-21 15:57 +0700
      Re: REST Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-21 14:24 +0100
        Re: REST JJ <duh@nah.meh> - 2013-08-22 00:22 +0700
    Re: REST Nobody <nobody@nowhere.com> - 2013-08-23 18:16 +0100
      Re: REST "Julio Di Egidio" <julio@diegidio.name> - 2013-08-23 19:50 +0100

#3674 — REST

Can someone help me understand what REST is in layman's terms?

I've read a lot about it, but I don't think I really get the essence of it.

It seems like a buzz word people just throw around without understanding it.

Thanks.

[toc] | [next] | [standalone]

#3675

On 21-Aug-13 1:00 AM, bob wrote:
> Can someone help me understand what REST is in layman's terms?
>
> I've read a lot about it, but I don't think I really get the essence of it.
>
> It seems like a buzz word people just throw around without understanding it.

Must be much like that mythical notion of "vacation". Heard about it, 
never experienced it myself :-D

[Jw]

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

#3676

On Tue, 20 Aug 2013 16:00:03 -0700 (PDT), bob wrote:
> Can someone help me understand what REST is in layman's terms?
> 
> I've read a lot about it, but I don't think I really get the essence of it.
> 
> It seems like a buzz word people just throw around without understanding it.

It's basically AJAX that's used to access web service API(s).

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

#3677

JJ <duh@nah.meh> writes:

> On Tue, 20 Aug 2013 16:00:03 -0700 (PDT), bob wrote:
>> Can someone help me understand what REST is in layman's terms?
>> 
>> I've read a lot about it, but I don't think I really get the essence of it.
>> It seems like a buzz word people just throw around without
>> understanding it.

There some truth in that.

> It's basically AJAX that's used to access web service API(s).

I think that puts the emphasis in the wrong place.  Many web services
are not accessed by browsers, and in those cases AJAX is probably not
involved.  The term refers to the style of the API: using HTTP through
get, put, post and delete methods to access and modify resources in an
otherwise stateless server.

-- 
Ben.

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

#3678

On Wed, 21 Aug 2013 14:24:59 +0100, Ben Bacarisse wrote:
> I think that puts the emphasis in the wrong place.  Many web services
> are not accessed by browsers, and in those cases AJAX is probably not
> involved.

You're right.

> The term refers to the style of the API: using HTTP through
> get, put, post and delete methods to access and modify resources in an
> otherwise stateless server.

And a view more, it seems.

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

#3683

On Tue, 20 Aug 2013 16:00:03 -0700, bob wrote:

> Can someone help me understand what REST is in layman's terms?

It's a set of design principles for web applications which promote
scalability and robustness.

AFAICT, most of it boils down to deciding on which side of the connection
to keep each piece of state.

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

#3684

"Nobody" <nobody@nowhere.com> wrote in message 
news:pan.2013.08.23.17.16.29.612000@nowhere.com...
> On Tue, 20 Aug 2013 16:00:03 -0700, bob wrote:
>
>> Can someone help me understand what REST is in layman's terms?
>
> It's a set of design principles for web applications which promote
> scalability and robustness.

<< Fielding describes REST's effect on scalability thus: "[...] increases 
the scalability of pure server components. [...]" >>
<http://en.wikipedia.org/wiki/Representational_state_transfer#Key_goals>

That scalability comes exactly at the cost of application components.  REST 
implements CRUD, which means direct access to data tables and all the data 
logic implemented on the client.  The overall architecture it enforces is 
then the opposite of ideal.  (Indeed, REST fits quite well into 
domain-driven design and its notion of plain persistence, but I consider DDD 
an architectural anti-pattern.)

> AFAICT, most of it boils down to deciding on which side of the connection
> to keep each piece of state.

That is how it is often presented, but, along the lines of what I have said 
above, just "keeping state" implies a very limited idea of service.

Julio
 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web