英文:
Is it possible to create an API endpoint in REST API if the resource is not an entity?
问题
我正在开发一个电子工资日记应用程序。在后端，我有一个名为"entries"的实体，其中包含"Date"属性。
现在我有一个React应用程序，它获取所有的entries，按月份和日期进行分组。但是我觉得在客户端上做了很多不必要的工作，因为我还有"payment"和"deduction"等实体，我也选择它们，总的来说，组件变得过载了。
问题是，如果我在后端创建一个"WorkingMonth"服务，在那里收集所有的信息，并通过某个API端点发布它，这样做是否正确？毕竟，没有这样的实体存在。
英文:
I am developing an electronic salary diary application. On the backend, I have "entries" entities with "Date" properties.
Now I have a react application that takes all the entries, groups them by month, and then by day. And it seems to me that I do a lot of unnecessary work on the client, because I also have such entities as "payment", "deduction" I also select them, in general, overloaded components are obtained.
Question. How much will it be right if I make a "WorkingMonth" service on the backend, and collect all the information there and issue it through some API endpoint? After all, there is no such entity.
答案1
得分: 1
首先，关于持久层中的数据存储方式不应该成为API设计的关注点。你的数据模型不是你的对象模型，你的对象模型也不是你的API模型。你正在意识到这一点。
这就是为什么你的API代码存在的原因，不仅仅是将数据库的列（或文档的属性）映射到JSON（或XML）结构，而是将适合你的代码的模型映射到适合你的API客户端的模型。
在服务器上将数据进行规范化并存储在关系型数据库中可能是有意义的，而客户端可能希望将一些相关数据组合在一起，以适应特定的上下文。
如果你只是想避免HTTP请求，因为客户端代码在遍历API暴露的关系时工作得很好（这可能与数据库中的表不同），你可以考虑嵌入一些资源，而不是创建一个新的“聚合”资源。但这确实取决于上下文。
此外，如果对客户端而言在多个资源中公开相同的数据是有意义的，那么完全没有问题。
英文:
First, how things are stored in your persistence layer shouldn't be a concern in terms of API design. Your data model isn't your object model, your object model isn't your API model. And you're realizing this.
That's why your API code exists, not to simply map columns on a database (or properties of a document) to a JSON (or XML) structure, but to map the model that works well for your code into a model that works well for your API client.
It may make sense to normalize the data and store it in a relational database on the server, while the client wants a bunch of related data together in something that makes sense in a specific context.
One thing you may want to keep in mind, if you're just trying to avoid the HTTP requests because the client code does work well traversing relationships your API exposes (which may be different than tables in a database) you could consider embedding some resources instead of creating a new 'aggregate' resource. But that really depends on the context.
Also, there's absolutely nothing wrong with exposing the same data in multiple resources, if that makes sense for the client.
答案2
得分: 0
如果在后端创建一个名为"WorkingMonth"的服务，并在那里收集所有信息，然后通过一些API端点发布它，那么这样做是非常正确的，从REST的角度来看。只有一个词汇问题（REST使用"资源"而不是"端点"）。
"任何可以命名的信息都可以成为一个资源" - Fielding, 2000
如何创建资源的表示是一个实现细节，隐藏在"统一"资源接口的后面。
英文:
> How much will it be right if I make a "WorkingMonth" service on the backend, and collect all the information there and issue it through some API endpoint?
From a REST perspective? It will be almost completely right -- there's only a vocabulary issue (REST has "resources", not "endpoints").
"Any information that can be named can be a resource" -- Fielding, 2000
How you create the representation of a resource is an implementation detail, hidden behind the "uniform" resource interface.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论