Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modern experience APIs undocumented #1689

Closed
baywet opened this issue Apr 18, 2018 · 13 comments

Comments

@baywet
Copy link
Contributor

commented Apr 18, 2018

Category

  • Question
  • Typo
  • Bug
  • Additional article idea

Expected or Desired Behavior

API's to come either under the SharePoint REST API or the Graph and to be documented, even if they are in beta.

Observed Behavior

As the modern experience is picking up, we have more and more customers that are asking us to build on top of it.
Things like "I'd like to see my saved for later news on my people-centric portal on the desktop", "I'd like the system to recommend me news I might be interested in", "I'd like to subscribe/follow sites, but from the news webpart..."
It appears the modern experience is leveraging 2 API's that are undocumented today:

For the first one I can see it's under SharePoint (good'ol vti bin...), just not under the _api yet and not documented, so a bit of cleanup plus documentation would be required here. Would it be possible to get at least a summary of what endpoints are available, payloads and supportability for this API fairly soon please? (Dear Vesa...)

For the second one I can't see a valid point for it being on it's own:

  • It's not under the SharePoint REST API or the Graph (yet another API I have to know about)
  • It has a dynamic domain name that's discoverable only within a page context, the token for it is passed with the page context as well... makes it super closed

When Microsoft came out with the Graph and then with the SPFX, something was repeated many times: have a first/third party API and extensibility model that'd provide a consistant experience for developers from all sides.
For this second api, if it's not "production ready" can you at least move it under the graph, beta and document it please? (Dear Vesa...) I know this is a "big" request that involves engineering, documentation, and the Graph teams...

@luismanez

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2018

Very interesting to know about it too. BTW, just pushed a new PR to the extensions repo showing how to use the "sphome.svc.ms/api/" API from code (which surely is not "supported").
SharePoint/sp-dev-fx-extensions#126

Cheers.

PS: love your dear-vesa area @VesaJuvonen !!! 😀

@baywet

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2018

Here is a uservoice entry to upvote the request as request by Vesa on today's SIG call https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/34075903-api-support-for-followed-sties

@luismanez

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2018

thanks @baywet ! voted up.

@patrickabel

This comment has been minimized.

Copy link

commented Jul 18, 2018

I'm using the followed-sites API currently on a few client web-parts and it, unfortunately, doesn't include modern team sites (with O365 Group) that have been followed. I would love to see the supported API include everything that we see with this undocumented endpoint.

@VesaJuvonen any updates incoming on this?

@mmsharepoint

This comment has been minimized.

Copy link

commented Jul 18, 2018

Vesa is on vacation but I am also curious on this.
I would also prefer this Api over the old Social.Following as it provides much better results/more attributes we might need.
@patrickabel I cannot confirm your findings. In my case the modern teamsites / Groups occur in the resukt once you follow them (on SharePoint site level) and occur as Type='Group' in the results while modern Coomunication sites occur as Type='Site' and WebTemplate='SITEPAGEPUBLISHING'
Best
Markus

@berndverhofstadt

This comment has been minimized.

Copy link

commented Aug 3, 2018

There is also a POST API to Stop following sites:
/_vti_bin/homeapi.ashx/sites/followed/remove
as body you need to send "https://<tenant>.sharepoint.com/sites/<site-to-unfollow>"

@BrianBusby

This comment has been minimized.

Copy link

commented Oct 10, 2018

@berndverhofstadt for the Stop call does the site address need to be assigned to a property in the body ie: body: { site: https://.sharepoint.com/sites/}`?

@berndverhofstadt

This comment has been minimized.

Copy link

commented Oct 10, 2018

@jeeakooma no it’s just the site between quotes in the body and no curly bracesOr property name :-)

@mpowney

This comment has been minimized.

Copy link

commented Jan 25, 2019

FWIW, Vesa responded to the question re support for *-sphome.svc.ms API's in a tweet in December 2018 - it's something that's planned long term, but with no ETA.

https://twitter.com/vesajuvonen/status/1070233837958062080

@2toLeadMike

This comment has been minimized.

Copy link

commented Feb 7, 2019

Note that /_api/sphomeservice/context?$expand=Token will provide both the token and the resource URL to target for working with many of these undocumented APIs.

@baywet

This comment has been minimized.

Copy link
Contributor Author

commented Feb 7, 2019

Update: it seems that even though the SharePoint home experience is still pointing to exotic endpoints, the follow/unfollow stores the information at the same location as the SharePoint REST follow API now:
https://docs.microsoft.com/en-us/sharepoint/dev/general-development/follow-content-in-sharepoint

Still a lot of endpoints are missing like suggested etc...

@justdevelopment

This comment has been minimized.

Copy link

commented May 2, 2019

As mentioned today in the SIG by Vesa, this is not looking good for official support. I've created a uservoice to get these functionalities added to an existing webservice such as Graph or the SharePoint REST Api. Please vote if you want to use these too :)

https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/37531192-add-modern-webservice-api-functionality-to-support

@VesaJuvonen

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2019

I'm closing this for now as this is more a feature request than actual issue. I do absolutely understand that we would need to have these documented, but that's not planned to happen for now until they are exposed through Microsoft Graph, which means that they will not be officially supported to be used by 3rd party developers.

Not an optimal situation, but let's ensure that we are asking them through the UserVoice and get some votes on them, so that they will be prioritized high on the internal engineering list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.