Inconsistencies in the Site design & Site scripts REST APIs

[waldekmastykarz]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

Site design and Site script APIs should follow generally accepted REST practices / OData protocols and at the very least, mirror what has already been adopted with existing SharePoint REST APIs.

similar to #1296

Observed Behavior

• HTTP Header CONTENT-TYPE requires charset

  All site design and site script operations require charset=utf8, which isn't used anywhere else in SharePoint.

• Inconsistencies when working with items in collections

  To get a site design or a site script you have to specify the ID in the body of the request:

  body: { id: <guid> }
  

  Why not use the collection pattern /_api/collection(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx) instead?

• GET operations require POST requests

  The following GET operations require at the moment issuing a POST request

  • get site design metadata
  • get all site designs
  • get site design rights
  • get site script metadata
  • get site scripts

  These are all GET operations that we should be able to perform using a GET request

• Performing operation on a site design or site script

  To update or delete a site design or site script you have to specify its ID in the body as part of the payload. This is inconsistent with other SharePoint APIs where the ID is specified in the URL as a part of the collection reference. The body should contain either only the metadata (update an item) or nothing at all (delete an item).

• Create site script

  When creating a site script, some parameters are specified in the URL where some (the actual script) are set in the body. This is inconsistent with other APIs in SharePoint (including the update site script API) where the whole payload is included in body

I understand that these APIs are still in preview. It would be good to have them consistent with other APIs in SharePoint once they reach GA.

[github-actions]

Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.

If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.

We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.