Questions tagged «web-api»

目前，我们的团队正在争论是否修改代码设计以允许单元测试是代码的味道，或者在什么程度上可以做到而又没有代码的味道。之所以如此，是因为我们只是刚刚开始实施几乎所有其他软件开发公司中都存在的实践。 具体来说，我们将提供一个非常薄的Web API服务。它的主要职责将是整理Web请求/响应并调用包含业务逻辑的基础API。 一个示例是我们计划创建一个将返回身份验证方法类型的工厂。我们不需要它继承一个接口，因为我们不希望它有任何具体类型。但是，要对Web API服务进行单元测试，我们需要模拟该工厂。 从本质上讲，这意味着我们要么设计Web API控制器类以接受DI（通过其构造函数或设置器），这意味着我们正在设计控制器的一部分，只是为了允许DI并实现我们原本不需要的接口，或者我们使用第三方框架（如Ninject）可以避免以这种方式设计控制器，但是我们仍然必须创建一个接口。 团队中的某些人似乎不愿意仅仅为了测试而设计代码。在我看来，如果您希望进行单元测试，则必须做出一些妥协，但是我不确定他们的担忧如何得到缓解。 需要明确的是，这是一个全新的项目，因此，它并不是真正地修改代码以进行单元测试。这是关于将要编写的代码设计为可单元测试的。

91 unit-testing  interfaces  web-api  asp.net-core 

我现在正在管理一个由15名开发人员组成的团队，而我们在选择技术时陷入了困境，该团队被分为两个完全相反的团队，就WCF与Web API的使用进行了辩论。 支持Web API使用的团队A提出了以下原因： Web API只是编写服务的现代方式（Wikipedia） WCF是HTTP的开销。这是TCP，Net Pipes和其他协议的解决方案 由于[DataContract]和[DataMember]以及这些属性，WCF模型不是POCO SOAP不像JSON那样可读性强 与JSON（通过HTTP传输）相比，SOAP是网络的开销 没有方法重载 支持WCF使用的团队B说： WCF支持多种协议（通过配置） WCF支持分布式事务 WCF有许多很好的例子和成功案例（虽然Web API仍然很年轻） 双工非常适合双向通讯 这场辩论仍在继续，我现在不知道该怎么办。我个人认为，我们应该仅在正确的使用位置使用工具。换句话说，如果我们想通过HTTP公开服务，则最好使用Web API，而在TCP和Duplex方面则要使用WCF。 通过搜索互联网，我们无法获得可靠的结果。支持WCF的职位很多，但相反，我们也发现有人对此表示抱怨。我知道这个问题的性质听起来可能有争议，但是我们需要一些好的提示来决定。我们处于一个偶然地选择技术可能会让我们后悔的时机。我们想睁大眼睛选择。 我们的用法主要用于Web，我们将通过HTTP公开我们的服务。在某些情况下（例如5％到10％），我们可能需要分布式事务。 我现在应该怎么办？如何以建设性的方式处理这场辩论？

49 wcf  decisions  web-api 

我对此很纳闷。 假设我有一个user资源id和name字段。如果我想更新一个字段，我可以像这样对资源进行PATCH请求 PATCH /users/42 {"name": "john doe"} 然后应用程序将更新用户42的名称。 但是，如果我重复此请求，结果会有所不同吗？ 根据RFC 5789 PATCH既不安全也不具有幂等性

48 rest  api-design  http  web-api 

我曾SignalR在多个项目中实现实时消息传递功能。它似乎工作可靠，并且非常易于学习使用。 至少对我来说，诱惑是放弃开发Web API服务，并将其SignalR用于一切。 我觉得这可以通过深思熟虑的设计来实现，如果可以的话，这意味着将需要更少的客户端代码。更重要的是，这将意味着将有一个单一的服务接口，而不是一个分离的接口，并且在最坏的情况下，可以将其连接起来而无需考虑何时渲染事物，等等。 因此，我想知道： 除了性能之外，还有其他原因不使用SignalR代替所有Web服务吗？ SignalR的性能是否足以引起人们的注意？ 能够将服务器端对象和服务定义转换为客户端服务访问代码而不用愚蠢的东西一直是我的梦想node.js。例如，如果我定义了一个有趣的对象InterestingObject以及该对象的服务，CRUD则InterestingObjectService可以定义到该服务的标准URL路由-例如“ / {serviceName} / {methodName}”，但是我仍然需要编写客户端代码才能访问服务。由于对象将被从客户端传递到服务器和背部，没有实际的原因有在客户端代码中显式定义对象，也无需显式定义执行CRUD操作的路由。我觉得应该有一种标准化所有方法的方法，这样就可以在假定服务访问从客户端到服务器再到服务器的工作透明的前提下编写客户端，就像我在编写WinForms或Java时一样Applet或Native App或您拥有的东西。 如果SignalR足以代替传统的Web服务使用，则它可能是实现此目的的可行方法。SignalR已经包含使集线器像我描述的服务那样工作的功能，因此我可以定义一个通用基础（CRUD）服务，该服务可以开箱即用地提供所有这些功能。然后，我几乎可以认为服务访问是理所当然的，这使我免去了重新编写代码以访问约定可以访问的内容的烦恼-更重要的是，我不得不花时间编写代码来定义如何对其进行更新。 DOM。 阅读我的编辑后，我觉得这可能有点荒谬，所以请随时问我是否对我的想法有疑问。基本上，我希望服务访问尽可能透明。

42 design-patterns  rest  web-api  websockets 

因此，我只是开始使用.Net WebApi，我要立即注意到的一件事是，没有合同定义API的外观和使用方式（每个动作的请求/响应），通常采用以下形式：用于WCF / Soap的WSDL。 在我看来，这将是非常有价值的事情，并使您的API使用者的生活变得更加轻松。 有没有理由吗？我是否不了解编程范例或原理？有什么办法可以创造一个？

33 c#  asp.net-mvc  web-api 

我正在MVC中具有移动应用程序的项目中工作，因此很明显，我们必须使用Web API，以便可以在移动应用程序中使用它。 在开始开发网站时创建了API之后，我们感到困惑，并讨论了是使用API​​还是直接访问Business对象。最后，我们让更多有经验的开发人员来使用Web API，而不是直接使用Business对象。 我对此解决方案结构感到困惑。 1）为什么我们应该使用Web API并发出HTTP请求（这很耗时）来获取或放置数据，而不是直接使用相同解决方案中的业务对象。 2）在争论之后，他们说如果客户端要在不同的云服务器上托管API和Web并仅在API上应用扩展，或者他想为访问API和Web使用不同的url（这是合理的）。因此，在那种情况下，我们应该在同一解决方案中从MVC应用程序调用Web API吗？ 3）如果我们将API和Web托管在不同的托管上，那么这意味着我们的Web将使用WebClient并在每个导航上都有HTTP调用。这样对吗？ 4）如果我们要在不同服务器上同时使用API​​和Web托管的业务对象，则BL中的某些更改将需要更新这两个服务器上的构建。 5）或者我们应该只为API创建一个项目，并且可以添加视图或html页面来开发Web界面，这样我们就可以直接从ajax调用API。 据我所知，＃5是最好的解决方案，或者API仅适用于第三方访问。如果我们在同一解决方案中具有DB，EF，数据层和业务层，则我们不应使用API​​进行HTTP调用并直接访问业务对象。（如果我错了，请纠正我）当移动应用程序或桌面或任何人想要访问应用程序时需要API，以便我们可以拥有相同的存储库和数据层。 在我的场景中，我必须创建API，因为我们也拥有移动应用程序，在项目API方面，我们称为业务层（单独的项目），业务层与数据访问层（单独的项目）进行通信。因此，我的问题是，如果我们将API和Web托管在不同的服务器上，那么调用API（这是一个HTTP请求）可能需要更长的时间，而不是在创建项目并且拥有.dll时使用业务层的方法。在API控制器中，我们只是将业务量转换为json格式。 我已经在互联网上进行搜索，但没有得到令人信服的答案。我发现了一个博客http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx，但又讨论了同一点在那个博客中，我的问题是为什么我们需要考虑场景＃3？ 更新：我们可以有不同的API项目和MVC项目，我们可以使用jvascript从Web调用API或使用MVVM模式。

33 project-structure  asp.net-mvc-4  web-api  asp.net-mvc-web-api 

有两节课： public class Parent { public int Id { get; set; } public int ChildId { get; set; } } public class Child { ... } 分配给时ChildId，Parent我应该首先检查数据库中是否存在它，或者等待数据库引发异常？ 例如（使用实体框架核心）： 注意，即使在官方的Microsoft文档中，这类检查也已遍及整个Internet：https：//docs.microsoft.com/zh-cn/aspnet/mvc/overview/getting-started/getting-started-with-ef-using- MVC /处理与实体框架在ASP.NET MVC应用程序中的并发处理＃修改部门控制器，但还有其他异常处理SaveChanges 另外，请注意，此检查的主要目的是向API用户返回友好消息和已知的HTTP状态，而不是完全忽略数据库异常。并且唯一引发异常的地方是在内部SaveChanges或SaveChangesAsync调用中...因此，当您调用FindAsync或时不会有任何异常Any。因此，如果子项存在但在此之前被删除，SaveChangesAsync则将引发并发异常。 我这样做的原因是，foreign key violation异常将很难格式化以显示“找不到ID为{parent.ChildId}的孩子”。 public async Task<ActionResult<Parent>> CreateParent(Parent parent) { // is this code redundant? // NOTE: its …

32 c#  entity-framework  orm  web-api  asp.net-core 

在过去的两家公司中，我曾经使用过REST API，用于通过Web应用程序查询数据。即。而不是让Web应用程序直接执行SQL，而是调用REST API，然后执行SQL并返回结果。 我的问题是...为什么要这样做？ 如果它要暴露给第三方，我可以理解。比完整的数据库更好地公开有限的REST API。但是在这两家公司中并非如此。 有人向我建议，这些REST API使在DBMS之间进行切换更加容易。但这不是数据库抽象层（DBAL）的重点吗？也许您将ORM用作DBAL，或者您可能只编写原始SQL并让DBAL在适当的情况下转换特定于DB的内容（例如，将MySQL的LIMIT转换为MSSQL的TOP）。 无论哪种方式，对我来说似乎都是不必要的。而且我认为这也使诊断问题变得更加困难。如果Web应用程序上的报告给出了错误的数字，则您不仅可以转储SQL查询，还必须转储REST URL，然后进入用作REST API的项目，并从中提取SQL。因此，这是一个额外的间接层，减慢了诊断过程。

32 database  web-applications  rest  web-api 

我正在构建一个REST API，具有不同角色的多个用户将可以访问它所包含的资源。 为了简化范围，让我们采用“学生/教师/班级”域： GET /students 是要访问的资源。 用户可能具有学生和/或老师之类的角色 学生将只能访问其班级的学生。老师将有机会接触所教课程的学生。一些用途可能是学生，也可能教其他课程。他们必须有权访问班级的学生和所教课程的学生。 理想情况下，我希望将其实现为两个功能-每个角色一个，如果用户具有多个角色，则“工会”。 我的问题是：我应该使用哪种模式来实现这一目标？ 在外部 我应该按角色划分API吗？GET /teacher/students而GET /student/students这似乎并不合适的给我。 保留所有这些，我是一种资源（首选） 内部地 应该如何在内部实施？ 每种方法都应该以BIG开关/如果每个角色开头吗？ 我应该为每个角色实现一个存储库吗？ 有没有一种设计模式可以帮助我实现这一目标？ 附带说明一下：我正在使用ASP.NET Web API和Entity Framework 6，但这对于概念性实现来说并没有关系。

27 design-patterns  programming-practices  rest  web-api 

创建RESTful API时，应该在相同的URL上使用HTTP动词（如果可能），还是在每个操作中创建特定的URL？ 例如： GET /items # Read all items GET /items/:id # Read one item POST /items # Create a new item PUT /items/:id # Update one item DELETE /items/:id # Delete one item 或使用特定的网址，例如： GET /items # Read all items GET /item/:id # Read one item POST /items/new # …

25 rest  api-design  web-api 

通过API传输对象时（如无模式JSON格式），返回不存在的字符串属性的理想方法是什么？我知道这样做的方式有很多，如下面列出的链接中的示例所示。 避免为空 传回null 删除空属性 我确定我过去曾经使用过null，但是没有足够的理由这样做。在处理数据库时，直接使用null似乎很简单。但是数据库似乎是一个实现细节，不应与API另一方有关。例如，他们可能使用无模式数据存储，该模式仅存储具有值的属性（非null）。 从代码的角度来看，将字符串函数限制为仅适用于一种类型（即string（非null））可以使它们更易于证明；避免null也是拥有Option对象的原因。因此，如果产生请求/响应的代码不使用null，那么我猜想API另一侧的代码也不会被强制使用null。 我更喜欢使用空字符串作为避免使用null的简便方法的想法。我听说过使用null并针对空字符串的一个论点是，空字符串表示该属性存在。尽管我理解了区别，但我也想知道这是否只是实现细节，使用null或空字符串是否会在实际生活中带来任何区别。我也想知道空字符串是否类似于空数组。 那么，解决这些问题的最佳方法是什么？它是否取决于要传输的对象的格式（schema / schemaless）？

25 web-api  data-types 

我正在创建一个API组合式Web应用程序，在此应用程序中，我们有不同的层，各自在工作。 第一层是验证用户输入的验证层，如果通过验证，则将其移至第二层（即访问控制层），否则返回错误消息 第二层是访问控制，它检查用户是否具有执行其想要执行的任务的权限，如果用户具有权限，则将请求移至下一层，否则返回错误消息 第三层是控制器层，我们具有应用逻辑 我的问题是在访问控制之前可以具有验证层吗？如果用户尝试执行用户没有权限的任务并且我们正在发回验证错误消息怎么办？用户将向端点发送请求并与验证层进行对话，并且仅在通过验证之后，他才会看到消息You can't access this! 我觉得很奇怪，所以这样还好吗？或者在基础设施方面我还有其他选择吗？

24 validation  web-api  access-control 

这可能是从Microsoft创建ASP.NET Web API库开始的，至少是在我没有记错的情况下记住它的时候。无论如何，从那时起，它的HTTP包就开始依赖于Newtonsoft.Json库进行数据往返于JSON的反序列化。 为什么像微软这样大的公司会增加对开源库的依赖？即使他们当时将使用.NET完全开源，我也觉得很奇怪，因为据我所知，它一直是唯一的非Microsoft库，用作依赖项。 作为一个奖励问题，詹姆斯·牛顿·金会从微软获得任何财务支持吗？

18 .net  asp.net  json  web-api 

我仍然记得存储库过去的美好时光。但是随着时间的流逝，存储库变得丑陋。然后，CQRS成为主流。他们很好，呼吸着新鲜空气。但是最近，我又一次又一次地问自己，为什么我不能在Controller的Action方法中保持正确的逻辑（尤其是在Web Api中，Action本身就是某种命令/查询处理程序）。 以前，我对此有一个明确的答案：我这样做是为了进行测试，因为很难使用所有这些不可模仿的单例和整体难看的ASP.NET基础结构来测试Controller。但是时代变了，如今，ASP.NET基础结构类对单元测试的友好程度更高（尤其是在ASP.NET Core中）。 这是一个典型的WebApi调用：添加了命令，并通知SignalR客户端有关此命令： public void AddClient(string clientName) { using (var dataContext = new DataContext()) { var client = new Client() { Name = clientName }; dataContext.Clients.Add(client); dataContext.SaveChanges(); GlobalHost.ConnectionManager.GetHubContext<ClientsHub>().ClientWasAdded(client); } } 我可以轻松地对其进行单元测试/模拟。而且，借助OWIN，我可以设置本地WebApi和SignalR服务器并进行集成测试（顺便说一下，速度非常快）。 最近，我越来越不愿意创建繁琐的命令/查询处理程序，并且我倾向于将代码保留在Web Api操作中。仅当重复逻辑或逻辑很复杂并且我想隔离它时，我才例外。但是我不确定我在这里做的事是否正确。 在典型的现代ASP.NET应用程序中管理逻辑的最合理方法是什么？什么时候将代码移动到Commands和Queries处理程序是合理的？有没有更好的模式？ 更新。我发现这篇关于DDD-lite方法的文章。因此，看来我将代码的复杂部分移至命令/查询处理程序的方法可以称为CQRS-lite。

15 .net  asp.net  web-api  cqrs  asp.net-mvc-web-api 

我们有一个ASP.NET Web API，它为我们的单页应用程序提供了REST API。我们使用DTO / POCO通过此API传递数据。 现在的问题是，随着时间的推移，这些DTO越来越大，所以现在我们要重构DTO。 我正在寻找如何设计DTO的“最佳实践”：当前，我们有一些小的DTO，它们仅包含值类型字段，例如： public class UserDto { public int Id { get; set; } public string Name { get; set; } } 其他DTO按组成使用此UserDto，例如： public class TaskDto { public int Id { get; set; } public UserDto AssignedTo { get; set; } } 另外，还有一些扩展的DTO是通过从其他对象继承来定义的，例如： public class …

13 rest  api-design  web-api  dto  poco