Rest SharePoint 2019应用程序的后端

我们正在为SharePoint ONPrem 2019应用程序开发几种基于SPFx的表单

什么是其后端的理想方法

扩展SharePoint的REST API 或 制作.net Core 3.1 WebAPI并公开为自定义服务

---

有什么建议吗？

“视情况而定”可能是正确的答案。选择您在SharePoint Server中托管的服务有一定的好处，但也有许多缺点。什么更合适或更简单在很大程度上取决于您希望后端有多复杂

在SharePoint Server中托管 这意味着您正在公开一个web服务，例如，在基于HTTP的WCF服务上使用ISAPI。这有一个很好的好处，即您在SharePoint中运行，因此您具有内置的身份验证功能，并且可以直接使用服务器端SharePoint API（SSOM）

另一方面，像这样托管您的服务也意味着您现在正在部署一个SharePoint场解决方案，其中包含了所有可能出现的问题（例如，部署更加复杂，开发过程通常会减慢，您可以想到的任何GAC问题）。当您在SharePoint中时，集成外部事物也会变得更加复杂

外部托管 如果您在外部托管您的web服务，那么您可以自由选择您想要的任何技术，并且不受SharePoint自身工作方式的限制。这也使得开发和部署变得更好，因为您可以选择任何处理这个问题的现代框架。外部事物的整合也变得容易多了

另一方面，您必须注意身份验证，这可能会带来自身的问题。如果您需要与SharePoint进行实际通信，则仅限于客户端访问，例如CSOM

说到CSOM，您必须记住，CSOM对SharePoint内部部署没有.NET核心支持。微软明确表示，在这方面没有任何工作要做，因此如果您想使用CSOM，您将被有效地锁定在.NET Framework中。这也意味着您很遗憾不能使用闪亮的ASP.NET Core 3.1应用程序，因为它只在.NET Core上运行。如果希望使用ASP.NET Core，则必须坚持使用2.1（这是最后一个仍在.NET Framework上运行的受支持版本），或者拆分您的体系结构，使ASP.NET Core应用程序不直接与SharePoint通信，而是将其工作转发给其他（.NET Framework）服务，然后再进行通信

---

---

因此，最终，这取决于您想做什么，以及您能够解决哪些问题。

随着时间的推移，如果您的后端仅依赖于SP列表和其他依赖项，我们找到的最佳解决方案是使用.Net FX完整版

---

否则，如果后端使用SQL server，则最好使用最新的.net内核。这也是因为，您可以从前端直接使用JSOM轻松完成一些较小的SP列表操作，而无需CSOM。

谢谢@poke先生。我们觉得有必要进行混合，这意味着SP（服务器场解决方案）上的一些REST服务需要从SP获取列表数据。我们将通过.net Core 3.1上的主要web API服务使用REST服务，我们的主代码可以在该服务中使用，因此我们可以利用像graphQL这样的所有技术堆栈。这样我们就可以同时使用SSOM和.net内核。