Re: REST "create if not exists"

Hi  François,

I'm addressing the *duplicate filters* issue from tha standpoint of user
interaction, which is what I do.
Not having that much information about your system, I´m free to guess so I
think the application and the users are regular.

The filters thing might is used by some teams to endorse some of their
responsabilities on the users. Especially, teams dominated by IT engineers
(like me).
We think *"this will allow them to do any query"* with emphasis in the word
"any".
Actually, non-IT people frequently can't do any query. What is simple to
us, like writing a boolean expression, requires a mindset that made us IT
guys. Non-IT people lack that mindset (have diverse mindsets) and thus they
can't translate a natural language requirement into an algebraic statement.
The typical example is a query for all people in Texas AND New York, doomed
to return zero items (we say TX and NY en English, but TX or NY in
boolean). That said, back to subject.

What I'm willing to communicate is that queries and filters have to be
written by IT people, on behalf of user's needs. This requires a previous
work to detect what the users really need, in order to provide them a
solution engineered by a pro. It might have to be a permanent task, albeit
once the users have what they want this tends to be quite stable.

Users can identify queries and filters by natural language descriptive
names, like "Monday morning events" or "Cash movements greater than $3333".
Not "123456".
Let them see a list of query/filter names where thay can choose, and
provide a "new" action so the boolean-savvy users can do their magic. Be
prepared to see few of these.

Users don't usually speak SQL or Boolean Algebra. They also don't speak
REST.
They don't want to, and they shouldn't need to, having IT pros around.

As a twist, I'd like to suggest (if your application is such that you
expect the users to do filters by the meny thousands) the implementation of
a normalization algorithm th reduce queries to a *signature *such as that
of OO methods in order to be able to recognize duplicates automatically and
merge them in statistics without any user involvement.
--
Juan Lanus







On Mon, Jun 4, 2012 at 12:58 AM, François Verry <[email protected]> wrote:

> **
>
>
> Thanks all for your answers.
>
> I have added the "cookbook" to my list just after posting this message,
> and I'll be buying it this week.
>
> As for the multiple advices here, I'll take them all. I'm not sure exactly
> what solution I'll finally get along with, but my question was more about
> understanding what makes the options valid or not. I'm glad you provided
> many distincts answers, and maybe, depending on the cases (as it seemed
> quite a common problem to me) I'll be using either one solution or the
> other.
>
> To answer the duplication issue, it occured to me that it may not be
> necessary. To be precise, the current system handles "grocery lists"
> duplicates :) But there are a lot of recordings, and I'm wondering if
> duplication doesn't prevents us from having statistics. If I treat the
> resource as "descriptive data", then I can duplicate them. But identifying
> each resource as unique would help knowing, for example, which filters are
> the most common.
>
> There is also another motivation : we have process running over those
> filters, that create notifications when a new result matches the filters.
> Reducing the number of filters will reduce the amount of time to process
> notifications as well.
>
> Then, thanks to you all, it is more clear in my head now :)
>
> François
>
> 2012/6/3 Philippe Mougin <[email protected]>
>
>> Hi François,
>>
>> I would go for #5 if possible. If you don't need to store and/or
>> manipulate filters as independent resources, you'll benefit getting them
>> out of your resource space, as this will vastly simplify your system.
>>
>> Now, instead of GET  /filters/{filter-id}/results you would do GET
>> /results?c1=foo&c2=bar&c3=baz. If your filters needs to be more complex
>> than a simple set of key/values, you can create a little syntax to express
>> them; e.g. : GET /results?filter=c1%3Dfoo%20ANDc2%3Dbar%20OR%20c3%3Dbaz.
>>
>> If you can't do that (maybe your filters are too long to fit in a URL
>> (but this probably isn't the case)), and if for some reason you absolutely
>> need to not have multiple URLs for identical filters, you should go for
>> your solution #2. The problem you see about it isn't a real one. This isn't
>> a fraud, as the meaning of POST isn't necessarily to append something, but
>> can be as generic as "Providing a block of data to a data-handling process".
>>
>> Best,
>>
>> Philippe Mougin
>>
>> Le 2 juin 2012 à 21:50, francoisverry a écrit :
>>
>>
>>
>> Hello
>>
>> I'm new to REST, and I'm trying to integrate it in my company. We
>> currently are trying to design a multi-criteria search engine with REST
>> principles. I use as a reference the O'Reilly "RESTful Web Services".
>>
>> I don't know if the following problem has been discussed somewhere, but
>> I've been unable to find anything that matches it. If you happen to know
>> resources that could help me, please let me know.
>>
>> In a multi-critera search engine, we have two types of resources :
>> "Results" and "Filters". Results are items searched for, and Filters are
>> sets of criteria which allows us to isolate a subset of Results.
>>
>> For example :
>>
>>     GET /results returns the total number of results
>>     GET /results/{result-id} returns one specific result
>>     GET /filters returns a specification on criteria usage (eg. an empty
>> <form>)
>>     GET /filters/{filter-id} returns one specific filter (eg. a filled
>> <form>)
>>     GET /filters/{filter-id}/results returns the total number of results
>> matching the filter, and links to the corresponding /results/{result-id}
>>
>> We want to allow the registration of filters. Imagine a filter as the
>> composition of 3 criteria, c1, c2 and c3. My first thought was to register
>> a filter through a POST request.
>>
>>     Request :
>>
>>     POST /filters HTTP/1.1
>>
>>     c1=foo&c2=bar&c3=baz
>>
>>     Response :
>>
>>     HTTP/1.1 201 Created
>>     Location: /filters/123456
>>
>> But if I (or someone else) do it again, I'll end up with another
>> {filter-id}, e.g. 123457. Then we'll have two resources with the exact same
>> meaning and content.
>>
>> If I want to use one URI for one criteria set, PUT seems more
>> appropriate. The thing is, the {filter-id} is assigned "randomly" by the
>> server. As a client, I can't guess nor force it. From there, I see the
>> following solutions, neither I find satisfying :
>>
>> 1/ I try to map artificially my URIs to the criteria set. I could use a
>> hash of the representation. e.g. :
>>
>>     Request :
>>
>>     PUT /filters/53c11504ba50e14b60407b13a72c0e53 HTTP/1.1
>>
>>     c1=foo&c2=bar&c3=baz
>>
>>     Response :
>>
>>     HTTP/1.1 200 OK
>>
>>     <form method="PUT" action="/filters/53c11504ba50e14b60407b13a72c0e53">
>>         <input name="c1" value="foo" />
>>         <input name="c2" value="bar" />
>>         <input name="c3" value="baz" />
>>         <input type="submit" />
>>     </form>
>>
>> The problem is : it is artificial. If my criteria set changes, or if its
>> representation changes, I could end up with conflicts or doubles.
>>
>> 2/ I trick the client into believing it actually created something new,
>> whether or not it has. This means, even if /filters/123456 already exists,
>> my server will answer it to anyone POSTing the "c1=foo&c2=bar&c3=baz"
>> content.
>>
>> The problem is : it's a fraud. Only the initial POST really "appends"
>> something.
>>
>> 3/ I answer the second-and-further POST requests with a "409 Conflict"
>> answer, and the correct location.
>>
>> The problem is : it is not actually an error. The client doesn't care to
>> register something, it just has no way to know wheter or not the resource
>> he is looking for already exists.
>>
>> 4/ I do a preliminary check
>>
>>     Request :
>>
>>     GET /filters?c1=foo&c2=bar&c3=baz HTTP/1.1
>>
>>     Response :
>>
>>     HTTP/1.1 301 Moved Permanently
>>     Location: /filters/123456
>>
>> The problem is : If the resource doesn't exists at that time, I'll be
>> willing to create it. If I do, nothing ensures me that someone hasn't
>> created it inbetween. Then, if I want to put aside a location for my
>> resource, it implies my GET isn't safe anymore.
>>
>> 5/ The last option I see is that the URI should contains the whole
>> content of the resource, as it is its "natural" identifier. This is
>> especially difficult if I have a large set of criteria, and if their values
>> are complex. This is why we use ids in the first place.
>>
>> Thanks in advance for your help
>>
>> François
>>
>>
>>
>  
>