locked
ODataEntry.Id vs ODataEntry.ReadLink RRS feed

  • Question

  • Hi;

    For the uri "http://services.odata.org/Northwind/Northwind.svc/Categories?$top=3", reading using ODataMessageReader, on the first EntryEnd the ODataEntry.ReadLink is null but ODataEntry.Id is "http://services.odata.org/Northwind/Northwind.svc/Categories(1)"

    Can I use the Id property us the uri to re-read that specific entry from the list of entries? And if ReadLink is not null, do I then use that instead?

    thanks - dave


    Who will win The International Collegiate Programming Championships?

    Friday, August 17, 2012 4:58 PM

Answers

  • ODataEntry.Id - is an ID - so identifier. It should be treated as an opaque string by the clients. (According to ATOM spec it should be an URI, so for example "urn:myid" is a valid ID). It is definitely not guaranteed to be a valid URL.

    ODataEntry.ReadLink is the read link for the entry, if the payload had it. In ATOM this maps to a link with "self" relation. It the payload doesn't have it, it will be null.

    Each entry should have at least one of ReadLink or EditLink. If an entry has only an EditLink, it can be used as a read link as well. EditLink maps in ATOM to the link with "edit" relation. So clients should use ReadLink for reading if available, otherwise fallback to EditLink.

    Couple of other related notes:

    - The reason the library doesn't do the "fallback" for you, is that we wanted the library not to "lie". So it reports what's on the wire. For a higher level API it would make total sense to implement the fallback transparently. I think WCF Data Services client does exactly that.

    - WCF Data Services Server generates the ID by pretty much using the edit link for the entity. This is common for OData services, but it's not a requirement anywhere in the spec. The service is free to choose whatever ID scheme it wants, especially one which is not a valid URL.

    Thanks,


    Vitek Karas [MSFT]

    • Marked as answer by DavidThielen Friday, August 17, 2012 6:59 PM
    Friday, August 17, 2012 5:19 PM
    Moderator

All replies

  • ODataEntry.Id - is an ID - so identifier. It should be treated as an opaque string by the clients. (According to ATOM spec it should be an URI, so for example "urn:myid" is a valid ID). It is definitely not guaranteed to be a valid URL.

    ODataEntry.ReadLink is the read link for the entry, if the payload had it. In ATOM this maps to a link with "self" relation. It the payload doesn't have it, it will be null.

    Each entry should have at least one of ReadLink or EditLink. If an entry has only an EditLink, it can be used as a read link as well. EditLink maps in ATOM to the link with "edit" relation. So clients should use ReadLink for reading if available, otherwise fallback to EditLink.

    Couple of other related notes:

    - The reason the library doesn't do the "fallback" for you, is that we wanted the library not to "lie". So it reports what's on the wire. For a higher level API it would make total sense to implement the fallback transparently. I think WCF Data Services client does exactly that.

    - WCF Data Services Server generates the ID by pretty much using the edit link for the entity. This is common for OData services, but it's not a requirement anywhere in the spec. The service is free to choose whatever ID scheme it wants, especially one which is not a valid URL.

    Thanks,


    Vitek Karas [MSFT]

    • Marked as answer by DavidThielen Friday, August 17, 2012 6:59 PM
    Friday, August 17, 2012 5:19 PM
    Moderator
  • Oh, ok. That all makes a lot of sense.

    thanks - dave


    Who will win The International Collegiate Programming Championships?

    Friday, August 17, 2012 6:59 PM