locked
Which format is better - "application/json" or "application/atom+xml" RRS feed

Answers

  • Hi,

    If you're using ODataLib to consume a service on the client end and the service supports both formats, then there are very few differences.

    - JSON payloads are usually smaller, and thus faster to transfer over the web and faster to process on the client. This is probably the biggest advantage of JSON over ATOM.

    - There are some slight differences in behavior between JSON and ATOM, but I would be very surprised if you actually ran into them, so you can consider the formats to be equal.

    - Some services store additional information in the ATOM payloads in the "ATOM" parts of the payload. For example the atom:title, atom:updated and so on. With ODataLib you can read this and the OM will expose it to you. But this is not very common and if you are just consuming the OData part of the service such data can be safely ignored anyway. So probably not a difference for you either.

    - Some services don't support the JSON endpoint. Not very common, but there are some. The ATOM seems to be supported more broadly, but it can change over time.

    So all in all JSON is probably better in this case just because it's smaller. On the other hand some people like to use ATOM since it is more humanly readable (it's just XML) and they want that added benefit to make the debugging easier for them with tools like Fiddler, but honestly one can read JSON by human eyes easily as well.

    Thanks,


    Vitek Karas [MSFT]

    • Marked as answer by DavidThielen Tuesday, August 7, 2012 4:56 PM
    Tuesday, August 7, 2012 7:07 AM
    Moderator

All replies

  • Hi,

    If you're using ODataLib to consume a service on the client end and the service supports both formats, then there are very few differences.

    - JSON payloads are usually smaller, and thus faster to transfer over the web and faster to process on the client. This is probably the biggest advantage of JSON over ATOM.

    - There are some slight differences in behavior between JSON and ATOM, but I would be very surprised if you actually ran into them, so you can consider the formats to be equal.

    - Some services store additional information in the ATOM payloads in the "ATOM" parts of the payload. For example the atom:title, atom:updated and so on. With ODataLib you can read this and the OM will expose it to you. But this is not very common and if you are just consuming the OData part of the service such data can be safely ignored anyway. So probably not a difference for you either.

    - Some services don't support the JSON endpoint. Not very common, but there are some. The ATOM seems to be supported more broadly, but it can change over time.

    So all in all JSON is probably better in this case just because it's smaller. On the other hand some people like to use ATOM since it is more humanly readable (it's just XML) and they want that added benefit to make the debugging easier for them with tools like Fiddler, but honestly one can read JSON by human eyes easily as well.

    Thanks,


    Vitek Karas [MSFT]

    • Marked as answer by DavidThielen Tuesday, August 7, 2012 4:56 PM
    Tuesday, August 7, 2012 7:07 AM
    Moderator
  • You say JSON, we'll use JSON :)

    thanks - dave


    Who will win The International Collegiate Programming Championships?

    Tuesday, August 7, 2012 4:57 PM
  • Actually thinking about it, I would suggest you craft an accept header such that you prefer JSON but can fallback to ATOM if available. ODL will decide which format to use based on the Content-Type of the particular response, so you won't even see that (unless you want to). The API behavior differences are there, but it's very easy to write your code to ignore them (in fact it's hard to write your code to not ignore them :-)) - so just ignore that for now, it should "just work".

    Eventually - when we release the JSON Light format (if you're interested there's a talk about that: http://channel9.msdn.com/Events/Open-Specifications-Plugfests/Odata-Meetup-2012/OData-Meetup-2012-JSON-Light-Detail, it changes since then a bit, but the general idea is there.) you could just tweak the Accept header to prefer that and update your ODL to support it, and it will "just work" as well.

    Hmm - there are actually quite a few interesting talks here: http://channel9.msdn.com/Events/Open-Specifications-Plugfests/Odata-Meetup-2012. I didn't realize they were taping it :-)

    Thanks,


    Vitek Karas [MSFT]

    Tuesday, August 7, 2012 5:21 PM
    Moderator