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

Modeling conditional update based on existence of a dependent resource

Expand Messages
  • Shaunak Kashyap
    Hi folks, I am looking to model an interaction in my REST application where the client should only be allowed to modify a resource (say B ) if another
    Message 1 of 7 , Jul 3, 2012
    • 0 Attachment
      Hi folks,

      I am looking to model an interaction in my REST application where the client should only be allowed to modify a resource (say "B") if another resource (say "A") exists.

      Using HTTP, if resource A exists, I would like PUT /uri/for/resource/B to succeed. If resource B does not exist, I would like the same PUT request to fail, responding with a status code that indicates to the client that resource A does not exist. So what is a good status code to respond with in the failure case? I considered 403 Forbidden but its semantics say that "the request should not be repeated". This does not quite make sense in my application since resource A might come into existence in the future, making it okay for the client to re-issue the same PUT request for resource B. 

      Alternatively (or additionally?), perhaps the client could issue a conditional PUT on resource B which would only succeed if resource A existed. How could I express such a condition in HTTP? I considered using the If-Match request header but that seems to apply to representations of the same resource (in my example, B) rather than of other resources (in my example, A).

      Thank you,

      Shaunak

      --
      "Now the hardness of this world slowly grinds your dreams away / Makin' a fool's joke out of the promises we make" --- Bruce Springsteen, "Blood Brothers"
    • Mike Kelly
      ... Would 404 not suffice here? ... You could use a Link header in the error response that has a relation type called something like depends-on-existence ,
      Message 2 of 7 , Jul 3, 2012
      • 0 Attachment
        On Tue, Jul 3, 2012 at 12:33 PM, Shaunak Kashyap <ycombinator@...> wrote:
         

        Hi folks,


        I am looking to model an interaction in my REST application where the client should only be allowed to modify a resource (say "B") if another resource (say "A") exists.

        Using HTTP, if resource A exists, I would like PUT /uri/for/resource/B to succeed. If resource B does not exist, I would like the same PUT request to fail, responding with a status code that indicates to the client that resource A does not exist. So what is a good status code to respond with in the failure case? I considered 403 Forbidden but its semantics say that "the request should not be repeated". This does not quite make sense in my application since resource A might come into existence in the future, making it okay for the client to re-issue the same PUT request for resource B. 

        Would 404 not suffice here?
         

        Alternatively (or additionally?), perhaps the client could issue a conditional PUT on resource B which would only succeed if resource A existed. How could I express such a condition in HTTP? I considered using the If-Match request header but that seems to apply to representations of the same resource (in my example, B) rather than of other resources (in my example, A).

        You could use a Link header in the error response that has a relation type called something like "depends-on-existence", and point that link to resource A.

        Cheers,
        M 
      • Mike Kelly
        ... Or if you preferred the link to be in the body you could use application/hal+json in the error response like so: { _links : { depends-on-existence : {
        Message 3 of 7 , Jul 3, 2012
        • 0 Attachment
          On Tue, Jul 3, 2012 at 12:38 PM, Mike Kelly <mikekelly321@...> wrote:
          >
          >
          > On Tue, Jul 3, 2012 at 12:33 PM, Shaunak Kashyap <ycombinator@...>
          > wrote:
          >>
          >>
          >>
          >> Hi folks,
          >>
          >>
          >> I am looking to model an interaction in my REST application where the
          >> client should only be allowed to modify a resource (say "B") if another
          >> resource (say "A") exists.
          >>
          >> Using HTTP, if resource A exists, I would like PUT /uri/for/resource/B to
          >> succeed. If resource B does not exist, I would like the same PUT request to
          >> fail, responding with a status code that indicates to the client that
          >> resource A does not exist. So what is a good status code to respond with in
          >> the failure case? I considered 403 Forbidden but its semantics say that "the
          >> request should not be repeated". This does not quite make sense in my
          >> application since resource A might come into existence in the future, making
          >> it okay for the client to re-issue the same PUT request for resource B.
          >
          >
          > Would 404 not suffice here?
          >
          >>
          >>
          >> Alternatively (or additionally?), perhaps the client could issue a
          >> conditional PUT on resource B which would only succeed if resource A
          >> existed. How could I express such a condition in HTTP? I considered using
          >> the If-Match request header but that seems to apply to representations of
          >> the same resource (in my example, B) rather than of other resources (in my
          >> example, A).
          >
          >
          > You could use a Link header in the error response that has a relation type
          > called something like "depends-on-existence", and point that link to
          > resource A.

          Or if you preferred the link to be in the body you could use
          application/hal+json in the error response like so:

          {
          "_links": {
          "depends-on-existence": { "href": "/uri/of/resource-A" }
          }
          }

          Cheers,
          M
        • Dan Haywood
          ... But the resource being put to DOES exist, so 404 doesn t make sense. To me it s more like a validation error, so consider 422 ( unprocesssable entity ).
          Message 4 of 7 , Jul 3, 2012
          • 0 Attachment
            On 3 July 2012 12:38, Mike Kelly <mikekelly321@...> wrote:
             

            On Tue, Jul 3, 2012 at 12:33 PM, Shaunak Kashyap <ycombinator@...> wrote:

             


            Using HTTP, if resource A exists, I would like PUT /uri/for/resource/B to succeed. If resource B does not exist, I would like the same PUT request to fail, responding with a status code that indicates to the client that resource A does not exist. So what is a good status code to respond with in the failure case? 

            Would 404 not suffice here?
             

            But the resource being put to DOES exist, so 404 doesn't make sense.

            To me it's more like a validation error, so consider 422 ("unprocesssable entity"). 

            Dan


          • Mike Kelly
            On Tue, Jul 3, 2012 at 12:45 PM, Dan Haywood ... The second sentence starts with If resource B does not exist , am I missing something? ... If 404 really
            Message 5 of 7 , Jul 3, 2012
            • 0 Attachment
              On Tue, Jul 3, 2012 at 12:45 PM, Dan Haywood <dan@...> wrote:
               



              On 3 July 2012 12:38, Mike Kelly <mikekelly321@...> wrote:
               

              On Tue, Jul 3, 2012 at 12:33 PM, Shaunak Kashyap <ycombinator@...> wrote:

               


              Using HTTP, if resource A exists, I would like PUT /uri/for/resource/B to succeed. If resource B does not exist, I would like the same PUT request to fail, responding with a status code that indicates to the client that resource A does not exist. So what is a good status code to respond with in the failure case? 

              Would 404 not suffice here?
               

              But the resource being put to DOES exist, so 404 doesn't make sense.

              The second sentence starts with "If resource B does not exist", am I missing something?
               

              To me it's more like a validation error, so consider 422 ("unprocesssable entity"). 


              If 404 really isn't right then 409 Conflict is probably the next best option in this case.

              Cheers,
            • Dan Haywood
              ... Ah... in which case you are right. However, given the question is phrased as an either/or, I suspect the OP meant to say if resource A does not exist... ,
              Message 6 of 7 , Jul 3, 2012
              • 0 Attachment
                On 3 July 2012 12:56, Mike Kelly <mikekelly321@...> wrote:


                On Tue, Jul 3, 2012 at 12:45 PM, Dan Haywood <dan@...> wrote:
                 



                On 3 July 2012 12:38, Mike Kelly <mikekelly321@...> wrote:
                 

                On Tue, Jul 3, 2012 at 12:33 PM, Shaunak Kashyap <ycombinator@...> wrote:

                 


                Using HTTP, if resource A exists, I would like PUT /uri/for/resource/B to succeed. If resource B does not exist, I would like the same PUT request to fail, responding with a status code that indicates to the client that resource A does not exist. So what is a good status code to respond with in the failure case? 

                Would 404 not suffice here?
                 

                But the resource being put to DOES exist, so 404 doesn't make sense.

                The second sentence starts with "If resource B does not exist", am I missing something?

                Ah... in which case you are right.

                However, given the question is phrased as an either/or, I suspect the OP meant to say "if resource A does not exist...", in which case 422 or, maybe, your 409 might work.

                I've asked in the past here about what should be used for validation errors, and 422 was the advice I got.  You might have been a respondent on one of those threads yourself, Mike.

                Dan

                 
                 

                To me it's more like a validation error, so consider 422 ("unprocesssable entity"). 


                If 404 really isn't right then 409 Conflict is probably the next best option in this case.

                Cheers,

              • Shaunak Kashyap
                I did intend to say if resource *A* does not exist , not resource B . Apologies for the typo and resulting confusion. Thank you for the discussion; this is
                Message 7 of 7 , Jul 3, 2012
                • 0 Attachment
                  I did intend to say "if resource A does not exist", not "resource B". Apologies for the typo and resulting confusion.

                  Thank you for the discussion; this is great!

                  Shaunak

                  On Tue, Jul 3, 2012 at 5:01 AM, Dan Haywood <dan@...> wrote:
                   



                  On 3 July 2012 12:56, Mike Kelly <mikekelly321@...> wrote:


                  On Tue, Jul 3, 2012 at 12:45 PM, Dan Haywood <dan@...> wrote:
                   



                  On 3 July 2012 12:38, Mike Kelly <mikekelly321@...> wrote:
                   

                  On Tue, Jul 3, 2012 at 12:33 PM, Shaunak Kashyap <ycombinator@...> wrote:

                   


                  Using HTTP, if resource A exists, I would like PUT /uri/for/resource/B to succeed. If resource B does not exist, I would like the same PUT request to fail, responding with a status code that indicates to the client that resource A does not exist. So what is a good status code to respond with in the failure case? 

                  Would 404 not suffice here?
                   

                  But the resource being put to DOES exist, so 404 doesn't make sense.

                  The second sentence starts with "If resource B does not exist", am I missing something?

                  Ah... in which case you are right.

                  However, given the question is phrased as an either/or, I suspect the OP meant to say "if resource A does not exist...", in which case 422 or, maybe, your 409 might work.

                  I've asked in the past here about what should be used for validation errors, and 422 was the advice I got.  You might have been a respondent on one of those threads yourself, Mike.

                  Dan

                   
                   

                  To me it's more like a validation error, so consider 422 ("unprocesssable entity"). 


                  If 404 really isn't right then 409 Conflict is probably the next best option in this case.

                  Cheers,




                  --
                  "Now the hardness of this world slowly grinds your dreams away / Makin' a fool's joke out of the promises we make" --- Bruce Springsteen, "Blood Brothers"
                Your message has been successfully submitted and would be delivered to recipients shortly.