One criticism I have heard placed at the door of ADO.NET Data Services is that it does not provide control over the syntax and design of the URI addresses that represent the resources you are surfacing through a data service. While it is true that there are limits to the control developers have over the formatting of URIs, most of these limitations are templating semantics rather than limiting how you structure your RESTful resources.
Many people who make this criticism want to use ADO.NET Data Services without the ADO.NET Entity Framework. This means you are losing the benefits of the Entity Data Model (EDM) that ADO.NET Data Services can consume as an implementation of IQueryable and IUpdateable. More specifically, you are losing the benefits of the conceptual model (CSDL) that is part of the EDM. While it is entirely possible to use data services with any given implementation of these interfaces (note that LINQ to SQL only implements IQueryable out of the box), you are resigning yourself to the limitations of these technologies. In other words, ADO.NET Data Services will only surface the classes that your LINQ implementation surfaces (in the case of LINQ to SQL this means classes that represent tables).
This blog post covers how to use the EDM effectively to present natural and readable entity URI addresses using ADO.NET Data Services. What is written here is only guidance, which means what I am suggesting is not fact, but merely an opinion based on my experiences of using ADO.NET Data Services and the Entity Framework through the course of writing my book, and my current project which uses both technologies extensively. Previous knowledge of ADO.NET Data Services and the Entity Framework is assumed. In particular how to address entities using ADO.NET Data Services (see chapter 3 of my book for more information if you are unclear about this).
Guideline 1 - Entity and Entity Set naming conventions
Single entities should be named as you would name any other single domain object: using a singular noun in PascalCase to best represent the object in question. Entity sets are most naturally addresses using a plural version of the entity name.
For example, the entity named Country would have an entity set named Countries, or the entity Customer would have an entity set named Customers.
Guideline 2 - Avoid using the entity's name in a scalar property name
As the entity is an object, there is no need to repeat the entities name in the scalar property name (as you might do for a table field to avoid ambiguous names across joined tables). Scalar properties should also be written as nouns in singular PascalCase like any other .NET object.
For example, an entity named Country may map to a table named Country with a field called CountryCode. In the Country entity, the property would be called Code. Therefore the object's property could be referred to by Country.Code.
Guideline 3 - Use natural keys as primary keys to entities
If there is an obvious candidate for a natural key, you are best using it as the entity's primary key. This is particularly true if the data is reference data that you are not truly the master of. For example, your service may need to expose countries that can be identified by a natural key of an ISO 3166 country code (such as GB, US and DE). The EDM has no concept of unique keys outside of the primary key. At first this seems like a limitation, but it is caused primarily because of the complexity of Create and Update operations if other key were used to address an entity; you would somehow need to map the natural key to the primary key for an update. If you are not the master of this data, your generated primary key is of no importance to a consumer anyway, so this limitation seems reasonable.
For example, if we had an entity called Country belonging to an entity set called Countries, a the country Great Britain could be addressed as:
http://myhost/myservice.svc/Countries('GB')
If the natural key is a composite key, the address reflects this. For example:
http://myhost/myservice.svc/TelephoneNumbers(CustomerId=123,Category='Work')
Identifies the work telephone number of the customer identified by id 123.
Guideline 4 - Navigation properties should be written as singular or plural nouns to reflect the multiplicity of the association
The EDM enforces both ends of an association between two entities. This means that each entity taking part in the association will contain a navigation property to the other entity. Associations can be either one-to-one, one-to-many or many-to-many. In each case, each end of the association has an inherent multiplicity, which should be reflected in the property's naming as either a singular or plural noun. Note that a plural noun will return an entity set.
For example, an entity named Country could have a one-to-many association with an entity named City. Therefore, the Country entity would contain a navigation property named Cities (indicating the many multiplicity) and the City entity would contain a navigation property named Country (indicating the one multiplicity).
So, the country (Great Britain) of the city of London might be addressed as:
http://myhost/myservice.svc/Cities('LON')/Country
And the cities found in the country of Great Britain might be addressed as:
http://myhost/myservice.svc/Countries('GB')/Cities
Guideline 5 - Use of Inheritance is limited by ADO.NET Data Services addressing
The EDM enables inheritance of entities using "table" inheritance. In other words, the EDM expects each entity sub class to map to a table. One restriction that ADO.NET Data Services places on to this model, is that each entity subclass cannot extend the properties of the base class (the service will throw an exception under these circumstances). The reason for this is because it is not possible to address each subclass using the same navigation properties if each subclass does not contain exactly the same properties as the base class. If you have entities that appear to be subclasses, but with additional properties, you should consider composition to duplicating properties between unique entities.
Summary
These guidelines have been formulated from experience of developing natural URI addresses to resources surfaced through ADO.NET Data Services and the Entity Framework. As a technology, ADO.NET Data Services is a good RESTful citizen, providing links to resources in any response to a URI, and following these guidelines promotes natural addressing that can be understood by anyone used to using the Internet.