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

Re: [rest-discuss] Content types and links

Expand Messages
  • Peter Williams
    ... Putting alternate links in the body is ok, but putting them in the HTTP header as link header fields[1] would better. It would make them visible to clients
    Message 1 of 8 , Sep 7 10:09 AM
    • 0 Attachment
      On Thu, Sep 6, 2012 at 3:18 PM, Greg Young <gregoryyoung1@...> wrote:
      >
      > Would it seem off to you that I gave you the alternates?

      Putting alternate links in the body is ok, but putting them in the
      HTTP header as link header fields[1] would better. It would make them
      visible to clients that do not understand how to interprete your
      particular flavor of JSON. Those clients are likely to be the ones
      that need alternate links the most.

      Also, you should strongly consider identifying your flavor of JSON
      with a vendor media type. Doing so allows clients to request (and
      interprete) its particular semantics. Having a specific media type is
      particularly helpful if/when you are going to serve more than one
      flavor of JSON. For example, if a standard atom+json ever really did
      come to fruition you would probably want to support both, for a while
      at least.

      [1]: http://tools.ietf.org/html/rfc5988

      Peter
      barelyenough.org
    • Greg Young
      Thats already there I just posted one of the formats of atom that can be gotten (+xml is also supported as is text + html) it depends what you send in your
      Message 2 of 8 , Sep 7 10:14 AM
      • 0 Attachment
        Thats already there I just posted one of the formats of atom that can be gotten (+xml is also supported as is text + html) it depends what you send in your accept header or url (yes I know this is "bad" but dealt with many that have problems getting headers working in their environments)

        The question was more is it worthwhile to send all of them if you have already picked one but I guess its fine to send. Guess it makes sense though that in some use case you could want one one way and another another way.

        re: mediatype we switched it.

        Cheers,

        Greg 

        On Fri, Sep 7, 2012 at 10:09 AM, Peter Williams <pezra@...> wrote:
         

        On Thu, Sep 6, 2012 at 3:18 PM, Greg Young <gregoryyoung1@...> wrote:
        >
        > Would it seem off to you that I gave you the alternates?

        Putting alternate links in the body is ok, but putting them in the
        HTTP header as link header fields[1] would better. It would make them
        visible to clients that do not understand how to interprete your
        particular flavor of JSON. Those clients are likely to be the ones
        that need alternate links the most.

        Also, you should strongly consider identifying your flavor of JSON
        with a vendor media type. Doing so allows clients to request (and
        interprete) its particular semantics. Having a specific media type is
        particularly helpful if/when you are going to serve more than one
        flavor of JSON. For example, if a standard atom+json ever really did
        come to fruition you would probably want to support both, for a while
        at least.

        [1]: http://tools.ietf.org/html/rfc5988

        Peter
        barelyenough.org




        --
        Le doute n'est pas une condition agréable, mais la certitude est absurde.
      Your message has been successfully submitted and would be delivered to recipients shortly.