Let’s Capture Missing or Insufficient SharePoint REST Endpoints

3 minute read

Today I got an alert that the SharePoint UserVoice suggestion from Corey Roth (@coreyroth) entitled Add managed metadata term store operations to REST API got the coveted “Thinking About It” tag from the Product Group. I like to tweet out changes like this to let people know the Product Group is listening and acting on our feedback – beyond saying “That’s good feedback!” It’s not all wine and roses, though:

Thank you for your feedback! Just letting you know that we absolutely have this in our backlog, but unfortunately this currently is not included in our short term engineering tasks. We absolutely understand the request and seeing vote counts around this, will help to further prioritize this work for next sprints.

I got a couple of tweets back right away pointing out some other current holes in the REST APIs.

If you think there are other endpoints the REST APIs need or endpoints that don’t work well, please add them to the comments here. I’ll work them up into a list for the Product Group and let’s see what we can get moving! We’ll play by the rules and add the list to UserVoice, but I think all the individual suggestions get lost and it’s harder to see the bigger picture. For each item on the list, I’ve tried to capture related UserVoice suggestions.

The list so far:

Lists

Calendars

Libraries

  • Version history (@merill) – Provide the Version History feature on list items with CSOM and/or REST, i.e. provide which metadata has changed with the previous value. Currently, the only way to retrieve versions is through the FileVersionCollection/FileVersion objects which provides only the VersionLabel, CreatedBy, CreationDate and Version Url. Ideally, we would need a ListItem object holding all the attributes and values for each version. (John Gunning)

Permissions

Managed Metadata / Taxonomy

Search

  • Recurring events via the Search endpoint (Derek Gusoff)

Publishing

  • Publishing – PublishingPageContent, PublishingPageImage (@gautamdsheth)

Workflows

  • Starting a site workflow – StartWorkflowOnListItemBySubscriptionId & StartWorkflow are only for list items (@BradOrluk)

Microsoft Graph

  • Easily get a graph access token (anonymous)

Groups

  • SharePoint groups – Changing group owners has a bug such that you can’t change them using REST (Mike)

User Profiles

  • Allow custom user profile property to be filtered using the $filter parameter (@gautamdsheth)

Other

  • Edit and manage web parts (anonymous)
Advertisements

38 Comments

  1. I think Rest is great enhancements but it needs more improvements such as search is limited to specific properties, like if I need to search users of a specific department or I need to search a user by email, rest is not going to help me.
    I have a list containing 1000s of records for last a few years and I need to extract data for any date range, from date and to date, despite the claims date ranges don’t work through rest api to filter custom lists.
    In document sets, through rest api, I cant filter with custom properties.
    In a common scenario, suppose I have a number of subsites and I have to display those sub sites as per user permissions. There is no function to bring sub site lists as per user permission. Therefore, 1st load all sub sites then check permissions and display to the user, is actually extra overhead.

    I believe a rich set of api or functions is needed to meet user expectations.
    Mostly errors that rest api returns are of no use, it could be more intelligent.
    In my intranet dashboard, I want to pull data from multiple other SharePoint bases applications but cross site is not supported in this case.

    Reply
    • @Mumtaz:

      I think some of your issues may not actually be issues.

      I agree that the REST endpoint for user profiles is not great, but unfortunately, that’s as much a function of the User Profile Service as it is the REST endpoint. Have you tried using search instead?

      I just did the following date/time filter on a Custom List, which worked fine:
      ?$filter=MyDate%20ge%20datetime%272017-05-15T00:00:00.000Z%27%20and%20EventDate%20le%20datetime%272017-05-15T23:59:59.000Z%27

      I also filter on custom properties in Document Sets all the time, so that should work.

      Making a call to /_api/web/webs should provide permission trimmed results.

      What version of SharePoint are you using? Can you provide specific errors which you think could use some improvement?

      M.

      Reply
  2. itemCount in RestApi needs improvement as well, currently its not supporting in combination with filter. itemCount returns counter of whole list and simply ignoress filters

    Reply
  3. Quite possibly. An example I’ve stumbled across rather than typing it out can be found here:
    https://social.msdn.microsoft.com/Forums/sharepoint/en-US/6c0b65cd-c3e0-4761-a70e-2235736ce0cc/cant-use-eventdate-or-enddate-when-filtering-calendar-items-using-rest-api?forum=sharepointdevelopment

    I have to go back to using ListData.svc or CAML in order to filter on them, rather than use the new REST API endpoint.

    Also as a side note, I want SPListItem.Versions in Powershell on SharePoint 365. Why it’s unavailable is beyond me! I guess I’ll just have to rely on the big wigs at MS to add it whenever they please :)

    Reply
  4. #1 one item that you are missing is to be able to set the PublishingAssociatedContentType via REST. You can set that via CSOM however the property is not avaiable via REST. This is useful in remote provisioning assets like Microsoft is recommending.

    There are more details here, I posted the issue on spsave plugin to see if they could figure out a work around other than what I already knew and they confirmed my findings.
    https://github.com/s-KaiNet/spsave/issues/28

    #2 accessing publishing images fields via REST … sigh… creating any js app where you interact with page layouts or list items this field is unable to be read unless you specific /fieldValuesAsText or /FieldValueAsHtml . Why this is frustrating is because you build an app using REST … then for this field you have to now use those extra words as above or use CSOM. Forget it if you have to set that field.. you will have to write a CSOM call for that.

    This goes into another area remote provision or data creation. I’m asked many times to pre-populate data and using pnp-js I can’t set that field. It’s unaccessible unless you write some CSOM. If you provision list data via XML in a sandbox solution you can set that field but I’m trying to utilize PNP-JS to create client data from external files like spreadsheets. I also use this technique to populate list data for semi-real testing of random content.. So I have something to work with when making page layouts, display templates ..etc.

    I posted a poorly worded (tired) user voice on this last week.
    https://officespdev.uservoice.com/forums/224641-feature-requests-and-feedback/suggestions/19395508-create-rest-end-point-for-set-and-get-publishing-i

    more items coming…

    Reply

Have a thought or opinion?