REST API Limitations On Premise and Workarounds

Question

I am just trying to understand the Limitations of the REST API in SP 2013 On Premise and it's workarounds. Can anyone please contribute with proper references?

Some of the limitations I have heard are (some may be incorrect, if so, please provide references to disprove).

1. REST API URL character limitation. I have heard the REST URL cannot have more than 255 characters. This means we cannot have complex or nested OData queries / conditions.

2. Bulk Insert / Update / Delete operations are not possible with REST API.

3. Paging with filters is not possible with REST URLs.

4. No way to get the item count from filter condition in On Premise (though this may be available in O365), although the listdata.svc has some provision to achieve this.

Can anyone please provide the other limitations and the possible workarounds, if any?

Answer 1

Limitation number #2 and #3 mentioned by OP is not correct. Find the explanation in the last part of the answer.

REST API Limitations-Workarounds

1. Nested query is not supported. Multiple REST call is workaround. See more here
2. $filter does not work with Calculated column. Using POST request and CAML query is workaround. See #1
3. $filter does not work with Multi Valued column. Using POST request and CAML query is workaround. See #1
4. Term Store Management is not supported. JSOM is workaround. See example here.
5. Maximum URL length is 260 in GET request. This value can be modified from web.config or Using POST request and CAML query is workaround. See #1.
6. Date Time functions are not supported but it works with listdata.svc. Example /_vti_bin/listdata.svc/SpTutorial?$filter=month(SpDateTime) eq 6. See more here.
7. Get Item count from filter is not supported. Using ListData.svc is workaround. Example _vti_bin/ListData.svc/Fruits/$count?$filter=((color eq 'red')). Find more here.
8. Batch request has support on SharePoint Online , on-premise SharePoint 2016 and later

My Explanation on OP's points

#1 has workaround. #2 and #3 are not the limitation. #4 is the limitation in on-premise and online both.

#1

You heard the right thing that default GET request length is 260. It can be modified from web.config. Another workaround you can make POST request instead of GET request to get item. In that case you will have to pass a CAML query.

End-point

/_api/Web/Lists/getbytitle('List Name')/GetItems

Request Body

    {
      __metadata: {
        type: "SP.CamlQuery" 
      },
      ViewXml: 'CAML Query goes here'
    }

#2

Bulk Insert / Update / Delete operations are possible using BATCH request. See following references for making BATCH request

Part 1 - SharePoint REST API Batching - Understanding Batching Requests

Part 2 - SharePoint REST API Batching - Exploring Batch Requests, Responses and Changesets

PS: Batch request has support on SharePoint Online , on-premise SharePoint 2016 and later.

#3

Paging and filtering is also possible in same query. You can achieve it using following operators.

• $filter
• $top

Example

/_api/web/lists/getbytitle('List Name')/Items?$filter=Status eq 'Accepted'&$top=10

You will get next page url as __next in your response.

Find more on paging and filter here.

#4

It is not possible in both environment (On-Premise and Online). But you can count items after getting the items.

Getting an ItemCount with filtering in SP2013 using REST api

How do I get the number of items in a list using REST?

Answer 2

Slight update, this does work on Sharepoint 2013 On Premise. You have to use "/_vti_bin/listdata.svc/$batch". When building the requests for http you must use the list url under the _vti_bin for it to work, rather than positing to the web _api like so, "/_vti_bin/listdata.svc/Testlist(" + obj.Id + ")". I have been able to delete 5k items in less than 15 minutes with 100 item batches, within our 2013 on prem env.