Questions tagged «rest»

在URL中指定REST API的版本是很普遍的，特别是在路径的开头，例如： POST /api/v1/accounts GET /api/v1/accounts/details 但是，我还没有看到将版本与每个API关联的任何设计。换句话说，我们分别维护每个API的版本。即： POST /api/accounts/v2 GET /api/accounts/details/v3 使用这种方法，当需要中断更改时，我们可以增加特定API的API版本，而无需增加整个API的版本。 使用此样式而不是通用样式有什么弊端？

15 rest  api-design  versioning  enterprise-architecture  engineering 

我们正在设计一个RESTful API，主要用于满足单个客户端的需求。由于其非常特殊的情况，此客户端必须发出尽可能少的请求。 API通过请求中的Accept-Language标头处理i18n。这适用于客户端需要做的所有事情，除了一项功能外，在该功能中，客户端需要在所有可用的语言环境中存储对单个端点的请求响应。 我们是否可以以某种方式设计API，使客户端可以在单个请求中获取所有这些信息，而又不会破坏一致的，结构良好的RESTful API设计？ 到目前为止，我们已经考虑的选项： 允许在Accept-Language标头中包含多个语言环境，并在响应中为所有请求的语言环境添加本地化版本，每个语言环境均以其ISO 639-1语言代码标识为密钥。 为该端点创建类似“？all_languages = true”的参数，并在响应中返回所有可用语言环境的本地化版本（如果存在该参数的话）。 （如果以上方法对我们都不起作用），将发出多个请求以从客户端获取所有本地化版本。 哪一个是最好的选择？

15 rest  api  api-design  http 

我的REST实现将使用以下结构在JSON中返回错误： { "http_response":400, "dev_message":"There is a problem", "message_for_user":"Bad request", "some_internal_error_code":12345 } 我建议创建一个特殊的响应模型，在该模型中，我可以传递所需的属性值（dev_message，message_for_user，some_internal_error_code）并返回它们。在代码中将类似于以下内容： $responseModel = new MyResponseModel(400,"Something is bad", etc...); 此模型应如何显示？是否应该在仅传递文本信息的地方实现例如successResponse（）这样的方法，并且那里的代码默认为200？我坚持这一点。这是我的问题的第一部分：我是否需要实现此模型，这是一种很好的做法吗？因为现在，我只是直接从代码返回数组。 第二部分是关于错误代码系统。错误代码将在文档中进行描述。但是我遇到的问题是代码。管理错误代码的最佳方法是什么？我应该在模型中编写它们吗？还是最好创建单独的服务来处理此问题？ 更新1 我已经实现了响应的模型类。这类似于格雷格的答案，逻辑相同，但是另外，我在模型中对错误进行了硬编码，这是它的样子： class ErrorResponse { const SOME_ENTITY_NOT_FOUND = 100; protected $errorMessages = [100 => ["error_message" => "That entity doesn't exist!"]]; ...some code... } 我为什么要这样做？那又是为了什么呢？ 代码看起来很酷： return new ErrorResponse(ErrorResponse::SOME_ENTITY_NOT_FOUND ); …

15 php  mvc  rest  api 

我正在构建.NET 4.5 C＃Web API RESTful解决方案，我想告诉我我的项目解决方案对于使用域驱动设计设计的解决方案是否正确和/或明智（足够？）。 该解决方案已分为6个项目： /基础 （没有任何引用） 该Web项目构成了解决方案与外界之间的接口。包含Web API控制器。除了从请求对象中收集值并要求BizApi层工作以外，几乎没有任何逻辑。 /Biz.Api （由基础引用） 提供域服务，并允许/ Base接口项目访问/Biz.Domain项目中的域业务逻辑对象。 /Biz.Domain （由Biz.Api引用） 提供Biz.Api层的域类。这些提供了操作内存中业务数据的方法。 /Dal.Db （由Biz.Api引用） 数据库存储库层。访问数据库并将返回的数据映射到/ Interfaces层中定义的内部DTO。 /Dal.Services （由Biz.Api引用） 为外部依赖项（如Web服务）提供代理层，并将其返回的数据映射到/ Interfaces项目中定义的内部DTO。 /接口 （以上大多数项目引用） 包含用于在解决方案中传递数据的DTO类和用于为IoC之类的合同定义合同的C＃接口。

15 c#  rest  domain-driven-design 

我正在编写Rest API，并且想知道如何最好地处理对不同版本的支持。这样，我不是要如何将URI定义为V2或V3，而是要根据需要构造代码： 同时支持多个版本，例如。V1＆V2＆V3 URI必须同时存在。当说V4来限制任何时候的支持量时，我将退出V1。 避免尽可能多的代码重复 轻松向一个版本添加不间断的更改，而不会影响其他版本 似乎可以采取的方法很少： 使用Git来控制版本，并为不同的版本提供分支（旧版本基本上不需要进行新的开发工作）。这将意味着没有代码重复，因为代码中只有最新版本，但是以前的版本将需要与DB的新版本一起使用，直到淘汰。 复制代码，以便每个版本都在同一应用程序中处理，并且具有完全独立的代码路径，但这将意味着大量重复 在各个版本中重复使用大量代码，但这将使维护变得困难，因为更改一个版本更可能影响先前版本 所有选项似乎都有自己的问题，是否有最佳实践来解决此问题？

15 rest  asp.net-mvc-web-api 

我正在构建一个REST API，该API允许插入（POST，而不是幂等）和更新（PUT，幂等）请求，以向我们的应用程序添加/更新数据库。 我想知道是否有关于在POST（插入）操作的响应中将哪些数据发送回客户端的标准或最佳实践。我们需要至少发送回一个记录ID值（例如，您的新记录是记录＃1234）。 我们应该以全部对象回应吗？（例如，它们基本上与从“ GET / object_type / 1234”请求中获得的响应相同） 我们是否应该仅使用新的ID值进行响应？（例如，“ {{id：1234}”，这意味着如果他们想获取整个记录，则需要执行额外的HTTP GET请求以获取完整记录） 重定向标头将它们指向完整对象的URL？ 还有其他东西吗？

15 rest 

如果我理解正确，那么REST被Roy Fielding正式化为Web体系结构的描述性模型。AFAIK Fielding并不认为REST很好，他只是在描述Web的实际架构。在这一点上，网络已经证明了一个巨大的成功的分布式超文本系统，因此，这种验证将REST作为主要由人类导航和使用的分布式超媒体领域的成功架构。 REST Web服务是通过将REST体系结构应用于API来创建的。但是实际上是否有任何理由认为REST是该领域的理想架构？更具体地说，是否有证据表明HATEOAS是机器对机器通信的有益设计原则？ 我担心的是HATEOAS对于超媒体有意义，因为很少有众所周知的内容类型（HTML，图像，视频等），并且客户端知道如何使用它们。但是对于API来说，内容类型是非常特定的，并且如果客户端经过专门编程以使用它们，则客户端只能以有意义的方式使用它们。向客户端返回URL本身并不能使客户端能够使用指示的资源。

15 rest  hateoas 

我读过许多有关微服务体系结构的文章，我想知道何时使用AMQP或REST。 我读到服务之间的松耦合是一件好事，在这种情况下，AMQP似乎是一个不错的选择。但是，如果我们使用AMQP，则意味着我们不再需要REST端点（但这意味着我们将失去HATEOAS概念）。 但是REST真的是构建我的服务的好方法吗？原因我将不使用任何端点...在这种情况下，一个端点比另一个端点更好？ 什么时候应该使用其中一个？

15 rest  api  web-services  microservices 

我正在考虑编写Web服务API，并且正在考虑创建REST服务。在这种情况下，OData是什么意思？您能解释一下OData和REST之间的区别吗？

15 rest 

我正在为比赛和日程表开发一个简单的RESTful服务。通过包含JSON正文的POST请求创建锦标赛时，会将锦标赛插入，BiMap在DAO实现中声明如下： private BiMap<String, Tournament> tournaments = Maps.synchronizedBiMap(HashBiMap.create()); 创建锦标赛时，将返回其关联的字符串ID，以便用户将来可以参考该锦标赛。他/她可以从执行以下请求的新锦标赛中获取信息： GET http://localhost:8080/eventscheduler/c15268ce-474a-49bd-a623-b0b865386f39 但是，如果找不到具有此类ID的锦标赛怎么办？到目前为止，我将返回204响应。好吧，泽西岛null从其中一种方法返回时正在为我做这件事。这是与上述路线相对应的方法： @Path("/{id}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament getTournament(@PathParam("id") String id) { Optional<Tournament> optTournament = tournamentDao.getTournament(id); if (optTournament.isPresent()) return optTournament.get(); return null; } 我的问题是：可以返回204: No Content响应，还是应该返回404响应，因为找不到资源？ 如果我应该将其更改为404，则会出现一个明显的问题：我应该更改方法签名吗？由于现在Tournament可能不会返回（类型为）锦标赛，因此方法应该看起来有所不同。我应该使用该Response类型作为返回类型吗？

15 java  rest  web-services  http 

我正在设计服务的REST API，并陷入了嵌套资源的正确方法。 资源：合作伙伴，票证，设置 资源之间的联系： 伙伴有很多票， 合作伙伴有一组设置， 业务逻辑： 您可以将所有合作伙伴列为匿名用户， 您可以将新票证添加为指定合作伙伴的匿名用户， 只有伙伴可以列出他的门票， 只有合作伙伴可以修改票证， 只有合作伙伴可以列出设置， 只有合作伙伴可以修改设置， 到目前为止，我所做的是： 合作伙伴资源 GET / partners-列出所有合作伙伴 GET / partners /：id-显示由：id参数指定的合作伙伴的详细信息 GET / partners /：partner_id / tickets-合作伙伴的票据列表 GET / partners /：partner_id / tickets /：id-详细信息指定伙伴的工单的 POST / partners /：partner_id / tickets-保存新工单 PUT / partners /：partner_id / tickets /：id-更新由：id参数指定的工单 GET / …

14 api  rest  api-design 

假设您使用的是供应商提供的API，如何确保其API可以正常工作？ 我主要担心的是有时供应商将更改推到他们的代码中并破坏API，我们希望有某种自动软件来不断对其进行测试。该如何处理？

14 testing  api  rest  continuous-integration  integration-tests 

根据Roy Fielding（HTTP规范的主要作者之一）在讨论REST时的开创性论文《建筑风格》中提到，他提到： 从客户端到服务器的每个请求都必须包含理解该请求所需的所有信息，并且不能利用服务器上存储的任何上下文。 通过“存储的上下文”他指的是应用程序的状态如什么下一页的页码是对资源的状态，例如任何数据存储，图像等-这可以说是整点休息。 可以公平地说，大多数纯休息尝试（据此定义为符合上述论点的实现）都必须失败，因为它们依赖于在服务器上存储会话数据（持久性还是其他方式）？ 会话的概念很常见-特别是对于Web开发人员-但是根据上面的定义它是否是RESTful的？

14 rest 

我们有一个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 

在设计API时，我们遇到了一个问题，即PUT有效负载是否应包含要更新的资源的ID。 这是我们目前拥有的： PUT /users/123 Payload: {name: "Adrian"} 我们的路由代码从URI中提取ID，然后继续进行更新。 API的第一批用户在质疑为什么我们在有效负载中不允许使用ID： PUT /users/123 Payload: {id: 123, name: "Adrian"} 我们不允许这样做的原因是因为ID在有效负载和URI中重复。 再考虑一下，我们正在将资源耦合到URI。 如果URI没有ID，则需要修改有效负载： PUT /no/id/here Payload: {name: "Adrian"} < What user??? 有什么理由不这样做吗？

13 rest  resources