Re: Re: the meaning of stateless

On 22.04.2013, at 20:56, "scott vernon" <[email protected]> wrote:

> I'm having this same debate with my development team as I try to convince them to switch from SOAP to REST. One of the functions requires quite a few input parameters so providing it all in the GET request would not work. 

Can you give an example?

'would not work' is my favorite indicator of design potential :-)

What you should do in general is to find named concepts and hierarchies and then use the URI path hierarchy to drill down into the 'pile of data'.

E.g.

instead of 

GET /orders?status=pending&region=US&amount-from=79.00&amount-to=999.00&query=smith

do sth like this:

GET /orders/pending/us/amount-range-2?query=smith

or if it makes sens from a business domain POV:

GET /pending-us-orders/amount-range-2?query=smith

This improves API clarity.

Get the idea?


Jan



> I suggest they do a POST and provide the URI back to the user. The problem is currently there isn't a backend database, so where would we store the intermediate data? If it is in memory does that reduce the ability to scale?
> 
> Any advice would be appreciated.
> 
> Thank you,
> Scott
> 
> --- In [email protected], Matt McClure <matthewlmcclure@...> wrote:
> >
> > On Apr 21, 2013, at 7:52 PM, Brian Craft <craft.brian@...> wrote:
> > 
> > 
> > 
> > Fielding's definition didn't do much for me, because the terms aren't
> > adequately defined, and there aren't enough examples to clarify his intent.
> > Also, some of the claims seem to be at odds with practice. Again, the "POST
> > to query" thing involves storing state between requests, while Fielding
> > says RESTful APIs are better because of "not having to store state between
> > requests". Well, which is it?
> > 
> > 
> > I think a key distinction is creating and destroying resources vs. other
> > kinds of state. The former is a key feature of REST.
> > 
> > And more generally, I'm trying to understand what REST is all about. It's
> > clear that the overwhelming majority of people who use the term REST
> > actually mean nothing more than AJAX. They merely haven't investigated at
> > all what it is supposed to mean. Of the small minority who mean something
> > more than AJAX, one gets the impression that there isn't any set of three
> > people who agree on what it means. So, it's a popular buzzword, and perhaps
> > a religion, but is it actually a design pattern, and is it actually useful,
> > and can it actually be used to design a substantial application with
> > existing technologies?
> > 
> > 
> > I recommend researching "hypermedia" for a higher signal to noise ratio
> > about REST.
> > 
> > 
> > Matt McClure
> > http://matthewlmcclure.com
> > http://www.mapmyfitness.com/profile/matthewlmcclure
> >
> 
> 



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/