Loading ...
Sorry, an error occurred while loading the content.

REST "create if not exists"

Expand Messages
  • francoisverry
    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
    Message 1 of 7 , Jun 2 12:50 PM
    • 0 Attachment
      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

    • mike amundsen
      François First, I highly recommend you check out the RESTful Web Services Cookbook [1]. It s full of very solid examples of solving problems /w HTTP. Second,
      Message 2 of 7 , Jun 3 12:36 PM
      • 0 Attachment
        François

        First, I highly recommend you check out the "RESTful Web Services Cookbook"[1]. It's full of very solid examples of solving problems /w HTTP.
        Second, you have quite a bit in this message and I'll only address some top-level items here.
        Third, FWIW, all your Qs seem to be related to the HTTP protocol, not Fielding's REST style; not a probem, just an observation.

        - "We want to allow the registration of filters."
        Your example of creating filters looks fine here. 

        - "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."
        And why is this a problem? does it crash your server? cause you to run out of storage? return bad results? cause business rules to go awry? I suspect you want to _optimize-out_ this seeming duplication. FWIW, I find it quite difficult to _prevent_ duplication in a distributed system and I only attempt it when it will crash the system or cause incorrect results. If two of the thousands of users I have in my system both store the same filter, results, list of groceries to purchase this weekend, I rarely care.

        I think most of the rest of your post here is dedicated to attempting something incredibly creative in order to prevent something extremely common<g>. 


        [1] http://shop.oreilly.com/product/9780596801694.do
        mca
        http://amundsen.com/blog/
        http://twitter.com@mamund
        http://mamund.com/foaf.rdf#me




        On Sat, Jun 2, 2012 at 3:50 PM, francoisverry <f.verry@...> wrote:


        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




      • Philippe Mougin
        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
        Message 3 of 7 , Jun 3 12:50 PM
        • 0 Attachment
          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


        • François Verry
          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
          Message 4 of 7 , Jun 3 8:58 PM
          • 0 Attachment
            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 <pmougin@...>
            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



          • Juan Lanus
            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
            Message 5 of 7 , Jun 4 7:04 AM
            • 0 Attachment
              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 <f.verry@...> 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 <pmougin@...>
              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




            • Will Hartung
              I talk about this here: http://stackoverflow.com/questions/1296421/rest-complex-applications/1297275#1297275 Notably I mention about normalizing the payload
              Message 6 of 7 , Jun 4 11:14 AM
              • 0 Attachment
                I talk about this here: http://stackoverflow.com/questions/1296421/rest-complex-applications/1297275#1297275

                Notably I mention about normalizing the payload and then simply redirecting to an existing filter.

                Another concept, on top of this, is to let the users name filters.

                This way you have two different domains. One is simply canonical filters that represent specific queries, while the other is conceptual filters that meet specific needs regardless of the actual criteria involved "Most popular users in the last month" for example, where that definition perhaps changes over time.

                Regards,

                Will Hartung
                (willh@...)


                CONFIDENTIALITY NOTICE: The information contained in this electronic transmission may be confidential. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by email reply and then erase it from your computer system.
              • Juan Lanus
                ... this way the users can search the query names domain in plain ...
                Message 7 of 7 , Jun 4 11:38 AM
                • 0 Attachment
                  ... this way the users can search the query names domain in plain <their language> ... 
                   

                  On Mon, Jun 4, 2012 at 3:14 PM, Will Hartung <willh@...> wrote:
                   

                  I talk about this here: http://stackoverflow.com/questions/1296421/rest-complex-applications/1297275#1297275

                  Notably I mention about normalizing the payload and then simply redirecting to an existing filter.

                  Another concept, on top of this, is to let the users name filters.

                  This way you have two different domains. One is simply canonical filters that represent specific queries, while the other is conceptual filters that meet specific needs regardless of the actual criteria involved "Most popular users in the last month" for example, where that definition perhaps changes over time.

                  Regards,

                  Will Hartung
                  (willh@...)


                  CONFIDENTIALITY NOTICE: The information contained in this electronic transmission may be confidential. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by email reply and then erase it from your computer system.


                Your message has been successfully submitted and would be delivered to recipients shortly.