Let’s Capture Missing or Insufficient SharePoint REST Endpoints

2 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:



      • After chatting with Marc, I should elaborate…

        The wrapper I wrote should highlight the hoops you have to jump through that aren’t necessary.

        The major pain point dating back to the asmx days are you need the ID of the workflow. What we really need is to be able to fire these workflows via display name. You can’t have a duplicates of the same workflow name, just like lists work, so it should be a guarantee that using the name will work as expected

        _api/web/workflows/wfName as a POST should fire; or site instead of web for site workflows. 2 cents from the front lines.

  1. Recurring events via the Search endpoint. Suppose I query for all events in May 2017, and the recurring event was created earlier than that. Search won’t return the May instances, nor will it return the original event.

  2. There is no REST API to read the column properties of a particular version history item in a document library. You can only read the latest version history.
    The inconsistency is that it is possible to do so for a list library.

  3. https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/15147150-provide-items-version-history-with-csom

    Better worded requirement for versioning

    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

  4. 1) Publishing fields like – PublishingPageContent, PublishingPageImage etc.
    2) Single Value taxonomy(managed metadata) column via a GET request
    (/_api/web/lists/getbytitle(‘ListName’)/items) endpoint, currently get guid.
    3) Ability to use $filter on Calculated column and Single value Taxonomy column label
    4) Allow custom user profile property to be filtered using the $filter parameter

    PS – Mark, minor correction , the twitter handle is @gautamdsheth and not @gautamsheth :)

  5. Thanks Marc!

    It’s already a serious list of missing features collected. Most of them aching from time to time causing face palms of how some issues or gaps could be there in SharePoint for years without any fixes. Like completely missing API to MMD or receiving single valued taxonomy column without switching to get by CAML method. Or Document Sets basics, even not a configuration, or file and documents versions API, or property bags.

    Let me add one more not mentioned by folks above, it is extending UPS methods with managing/modifying properties for profiles of other users (the methods presented in CSOM).

  6. Hello Marc,

    Expand ($expand) fields shouldn’t return an error when the field is null, when using _api/web/Lists… it works when you are using the legacy api /_vti_bin/ListData.svc

    The ability to filter by a multiline column.

    Those are the ones off the top of my head.

    Congratulations for the initiative.


Have a thought or opinion?