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

Re: [rest-discuss] How to identify existing resource in a POST(a) request

Expand Messages
  • Paul Moore
    Markus, Your observation of the demands of hypermedia is exactly the point. 1) Why would / should Facebook provide a link to a specific service? 2) Without
    Message 1 of 10 , Oct 29, 2012
    • 0 Attachment
      Markus,

      Your observation of the "demands of hypermedia" is exactly the point.  

      1) Why would / should Facebook provide a link to a specific service?  
      2) Without such a link, where should the "hypermedia following" client go?
      3) Even if they (Facebook) desired to provide such a link, would this be possible? (presumably they would need some understanding of the resource state within the example.com domain)

      I think what is becoming more clear (through this discussion) is that hypermedia links have to be provided by an authoritative source (in this case example.com).  How non-authoritative resources can interact in the media-type across "agency boundaries" is more complex, and needs more research (certainly be me, perhaps it's obvious to others).

      Back to the 'Referer' question, I was investigating this partly to see if a standard HTTP header could be used instead of hyperlinks in some circumstances.  Digging back through the archives, I've found some commentary from Phill Hallam-Baker (proposer of the 'Referer' header) here, where he articulates the header's "intended purpose of making links bidirectional".  This intended purpose seems somewhat aligned, but I'm guessing that years of usage for tracking purposes has devalued the semantic a little (I'll think I'll get in touch with Phill directly on this).

      So, I think that I am concluding that usage of the 'Referer' header for my purpose is incorrect, but it's on the basis of "common-usage" rather than conflict with the standard [RFC2616].

      Thanks

      Paul


      On 27 Oct 2012, at 16:14, Markus Lanthaler wrote:

      So you are saying that every representation of a person has to contain a
      link to your "friend service"? So, to take your example,
      graph.facebook.com/2 must somewhere contain a link to example.com/friends?
      Otherwise, how did that URI "initiate the request"?

      I think HTTP (bis) is quite clear on this:

      The "Referer" [sic] header field allows the client to specify the URI
      of the resource from which the target URI was obtained (the
      "referrer", although the header field is misspelled.).

      So I would say it's a bad design decision to use the referer header for the
      scenario you are outlining.

    • Paul Moore
      Nathan, Firstly, thanks for the response. I ve taken a look at the myprofile-project.org and it looks promising. From what I can deduce it s based on the FOAF
      Message 2 of 10 , Oct 29, 2012
      • 0 Attachment
        Nathan,

        Firstly, thanks for the response.

        I've taken a look at the myprofile-project.org and it looks promising.  From what I can deduce it's based on the FOAF work, which in turn is built on RDF.  As we're currently a bit of a JSON shop, it's somewhat tricky to directly translate this, but I'll pick this up with Andrei directly.

        I think your Option A is the most palatable, as frankly instead of a "friend-request" representation, this can just be a "friend" representation which then links to a person.  This nicely separates the relationship semantic from the entity semantic, and thus (as with all 'resource-parititioning") the cache concerns can be independently handled / optimised.

        I'm still somewhat sceptical of the use of the "self link" as in most cases (all cases for my current usage) it's just a restatement of the Request-URI (or redirection thereof), but, the separate representation simplifies the problem.  Perhaps I had over-collapsed the representation design and just needed to back-away a little.

        Anyway, thanks for the thinking.

        Best regards

        Paul


        On 27 Oct 2012, at 14:34, Nathan wrote:

        Hi Paul,

        Uniform Resource Identifiers (URIs) are certainly the best choice for identifiers on the Web.

        It appears that you want to POST a representation of a person to /friends in order to have the person described by the representation added as a friend of the currently authenticated user.

        If this is correct, then I'd encourage you to:

        A) describe the action you want performed with a representation (friend request) and POST that instead.

        B) refactor things such that either:

        B1) the representation at example.com/persons/1 contains a list of that persons friends, a list which you update by POSTing annotations (friend requests) to, or update by PATCHing it, or by PUTting a new representation.

        B2) create a resource example.com/persons/{local-identifier}/friends which is a list of for each person, and again POST, PATCH or PUT to update it.

        In all honesty though, your best bet here is most likely to take a look at myprofile-project.org and speak to Andrei Sambra <andrei@...> as they've nailed exactly what you want to do. Identification of agents making request, and open profiles of them are provided by WebID and Linked Data. This really appear to be what you need for this scenario (and probably all scenario's you can think of).

        As a side note, you can identify who is making a request by requiring auth* when the person makes it, or by using the From header in the request (although this is rather limited as it only takes identifiers of the formuser@..., which then leads you down the road of needing WebFinger to lookup users).

        Ultimately, the exact method on how you implement this depends on which mediatype(s) you end up using, at an abstract level it's just a simple three-tuple truth statement you want to send though "<example.com/persons/1> friend <example.com/persons/2>", via auth* you can find out whether it's '<example.com/persons/1>' updating their profile, or <example.com/persons/2> making a friend request.

        Best,

        Nathan

      • Nathan
        ... JSON-LD can help you there, or the JSON encoding of microformats :) ... Exactly. ... It does have it s uses, especially rel= canonical for several
        Message 3 of 10 , Oct 29, 2012
        • 0 Attachment
          Paul Moore wrote:
          > Nathan,
          >
          > Firstly, thanks for the response.
          >
          > I've taken a look at the myprofile-project.org and it looks promising. From what I can deduce it's based on the FOAF work, which in turn is built on RDF. As we're currently a bit of a JSON shop, it's somewhat tricky to directly translate this, but I'll pick this up with Andrei directly.

          JSON-LD can help you there, or the JSON encoding of microformats :)

          > I think your Option A is the most palatable, as frankly instead of a "friend-request" representation, this can just be a "friend" representation which then links to a person. This nicely separates the relationship semantic from the entity semantic, and thus (as with all 'resource-parititioning") the cache concerns can be independently handled / optimised.

          Exactly.

          > I'm still somewhat sceptical of the use of the "self link" as in most cases (all cases for my current usage) it's just a restatement of the Request-URI (or redirection thereof), but, the separate representation simplifies the problem. Perhaps I had over-collapsed the representation design and just needed to back-away a little.

          It does have it's uses, especially rel="canonical" for several
          similar/identical resources.

          However, it's also useful to consider the messages, and look to those.
          After all you can model the state of a resource within a protocol as a
          function of all the messages to date - or - the current state (Sn) as a
          function of a message M and a previous state (Sn-1), and time T. That is
          to say, it's the messages which change the state of a resource. So any
          resource which changes it's state by way of messages, would do well to
          consider those messages, especially the effective-request-URI for the
          resource currently being interacted with / requested. I know HTTP is
          often "black-boxed" by components to hide the implementation details
          (especially request lines and headers), but they're pretty vital to
          building RESTful services!

          Best,

          Nathan

          > Anyway, thanks for the thinking.
          >
          > Best regards
          >
          > Paul
          >
          >
          > On 27 Oct 2012, at 14:34, Nathan wrote:
          >
          >> Hi Paul,
          >>
          >> Uniform Resource Identifiers (URIs) are certainly the best choice for identifiers on the Web.
          >>
          >> It appears that you want to POST a representation of a person to /friends in order to have the person described by the representation added as a friend of the currently authenticated user.
          >>
          >> If this is correct, then I'd encourage you to:
          >>
          >> A) describe the action you want performed with a representation (friend request) and POST that instead.
          >>
          >> B) refactor things such that either:
          >>
          >> B1) the representation at example.com/persons/1 contains a list of that persons friends, a list which you update by POSTing annotations (friend requests) to, or update by PATCHing it, or by PUTting a new representation.
          >>
          >> B2) create a resource example.com/persons/{local-identifier}/friends which is a list of for each person, and again POST, PATCH or PUT to update it.
          >>
          >> In all honesty though, your best bet here is most likely to take a look at myprofile-project.org and speak to Andrei Sambra <andrei@...> as they've nailed exactly what you want to do. Identification of agents making request, and open profiles of them are provided by WebID and Linked Data. This really appear to be what you need for this scenario (and probably all scenario's you can think of).
          >>
          >> As a side note, you can identify who is making a request by requiring auth* when the person makes it, or by using the From header in the request (although this is rather limited as it only takes identifiers of the formuser@..., which then leads you down the road of needing WebFinger to lookup users).
          >>
          >> Ultimately, the exact method on how you implement this depends on which mediatype(s) you end up using, at an abstract level it's just a simple three-tuple truth statement you want to send though "<example.com/persons/1> friend <example.com/persons/2>", via auth* you can find out whether it's '<example.com/persons/1>' updating their profile, or <example.com/persons/2> making a friend request.
          >>
          >> Best,
          >>
          >> Nathan
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.