Re: Content types and links

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 <[email protected]>wrote:

> **
>
>
> On Thu, Sep 6, 2012 at 3:18 PM, Greg Young <[email protected]>
> 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.