The SharePoint RESTful API (ListData.svc) is a great and effective way to access data in SharePoint lists and document libraries for use in mobile/desktop web apps. However, you should be aware of some of the limitations of ListData.svc in SharePoint 2010.
-
Anonymous access not allowed.
Only authenticated users can use ListData.svc, even for lists that allow anonymous access. This means you can’t use ListData.svc in public sites.
-
Property names based on display names instead of internal names
In contrast to SharePoint Web Services and CSOM, which use internal names of the item fields, ListData.svc uses the display names (with whitespace trimmed). This can cause issues when your user changes the display names of columns or if your user can switch languages in a multilingual SharePoint site (the display names of fields may change).
-
No access to External List
You cannot access (read or write) data in SharePoint External Lists.
-
No access to discussion list
ListData returns HTTP 500 error when accessing a Discussion list. This is confirmed as a bug and has been escalated to the development team. More details here.
-
Cannot use $filter beyond resource throttling threshold
You cannot filter on a list with more items than the throttling threshold. ListData.svc does not take into account the use of folders. Full details in this blog post.
Did you encounter any other limitations? Let me know and I’ll update the post.
... And All That JS 
Hi Luc, The finding 5 with $filter is interesting. I’m wondering if creating an indexed column for the columns you want to filter on would mitigate that issue. IIRC this is a MS recommendation when dealing with larger lists.
It doesn’t seem to work with Custom Fields written in Visual Studio either.
Pingback: Everything I need to know about RSS and XML Viewer Web Part (WP) « Automate IT!
Usefull post … although it shows that SharePoint API is netiher “great” or “effective” ….
No ability to filter items created by “ME”, without specifying the correct User ID. With web-services and CAML you can use which automatically resolves to the currently logged in user. You can use _spPageContextInfo.userId to get the ID of the currently logged in user, but that won’t exist on a custom page without further trickery.
That should be “… you can use <UserID /> which automatically …”
#1 on this list should be “No managed metadata fields” in REST API, forces you to fall back on SPServices library.
Also no indexing on standard “Name” field so filtering based on name on large lists results in an error: /_vti_bin/listdata.svc/Items?$filter=Name eq ‘Something’
Does not work with Surveys as well. I get a 500 Internal Error message.
There is a row limit of 1000 items. This limit is set in the Microsoft.SharePoint.Linq.DataService.dll:
See https://gilleslauwers.wordpress.com/2010/12/08/ado-net-data-services-returns-1000-items/