为了与EmberData的互操作性,似乎每当发生验证错误时我需要用422(Unprocessable Entity)而不是400(Bad Request)来回复.我有两个问题:
和奖金:
我正在研究一个应用程序,我们正在研究使用jsonapi来描述所有API响应中的数据的可能性.它对于类似资源的实体非常有效,但我们在提出一种以类似jsonapi的方式描述报告数据的方法时遇到了一些麻烦.
通过报告数据,我指的是从我们存储在数据库中的基本资源类数据中即时聚合和计算的数据.例如,想象一下我们存储房地产信息,我们有关于房屋,公寓和办公空间的信息,每个都与位置,房屋面积(平方英尺),房产类型(房屋,公寓或办公空间)相关联,以及有关房产的任何其他相关信息.现在想象一下,我们需要一个接收的报告,?group_by[]=location&group_by[]=type我们希望响应能够传达有关这两个group_by参数交集的汇总信息.因此,我们将收到一个对象,其中包含给定位置中所有属性的平均平方英尺面积,也按属性类型分组.
Average Property Sizes (in square feet)
Houses Apartments Offices
Manhattan 1234.56 234.56 123.45
Cape Coral 456.78 654.32 876.54
Portland 4321.00 987.65 2345.67
Run Code Online (Sandbox Code Playgroud)
我们可以从这些数据中想到的最类似资源的是每个单元格,但由于它们是更多基本数据的计算聚合的结果,因此它们没有自然ID.我们一直在思考与计算ID提交他们以及(也许结合通过它们的数据分组的尺寸,即的ID "house,34",其中house代表一种类型的属性,34是位置"曼哈顿"的ID).然后,每个单元将与相应的位置记录具有关系,该记录将包括在included有效载荷的部分中.这是一个示例json文件的示例:
{
"data": [
{
"id": "house,123",
"type": "report_items",
"attributes": {
"property_type": "house",
"value": 108.75
},
"relationships": {
"location": {
"data": {
"type": "locations",
"id": 123
}
}
}
},
{
"id": "house,124",
"type": "report_items",
"attributes": {
"property_type": "house",
"value": 36.0
},
"relationships": { …Run Code Online (Sandbox Code Playgroud) 目前,我正在研究新产品,并为公共和内部需求制作REST API。我从{json:api}规范开始,对它感到非常满意,直到遇到一些无法找到答案的问题。
根据JSON API规范,每个资源都必须包含id。
每个资源对象必须包含一个id成员和一个type成员。id和type成员的值必须是字符串。
在很多情况下都可以,但不是全部。
我们的大多数端点都是关于“资源”的
如果我要收集“东西”(http://example.com/things)
{
"data": [{
"type": "things",
"id": "1",
"attributes": {
"title": "first"
},
"links": {
"self": "http://example.com/things/1"
}
}, {
"type": "things",
"id": "1",
"attributes": {
"title": "second"
},
"links": {
"self": "http://example.com/things/2"
}
}]
}
Run Code Online (Sandbox Code Playgroud)
如果我只要求一个“物”资源(http://example.com/things/1)
{
"data": {
"type": "things",
"id": "1",
"attributes": {
"title": "first"
},
"links": {
"self": "http://example.com/things/1"
}
}
}
Run Code Online (Sandbox Code Playgroud)
但是如何处理与资源无关且没有ID的终结点呢?
例如,在我们的应用程序中,存在一个端点http://example.com/stats,该端点应返回当前登录用户user的统计信息。喜欢 …
暂时忽略3xx响应,我想知道为什么HTTP位置标头仅与POST请求/ 201(创建)响应一起使用.
来自RFC 2616规范:
对于201(已创建)响应,Location是请求创建的新资源的位置.
这是一种受到广泛支持的行为,但为什么不应该将其与其他HTTP方法一起使用?以JSON API规范为例:
它为JSON有效负载内的当前资源定义了一个自引用链接(对于RESTful API来说并不罕见).此链接包含在每个有效负载中.该规范说,你必须包括HTTP标头的位置,如果你创建通过POST,且这个值是一样的,在有效载荷自参考链接一个新的文件,但是这仅需要POST.如果您可以使用HTTP位置标头,为什么还要使用自引用链接的自定义格式?
注意:这不是特定于JSON API的.这是对同一HAL,JSON的Hyper-模式或其他标准.
注意2:它甚至不是特定于HTTP位置标头,因为它与HTTP链接标头相同.正如您所看到的,JSON API,HAL和JSON Hyper-Schema不仅定义了自引用链接的约定,还表达了有关资源的相关资源或可能的操作的信息.但似乎他们都可以使用HTTP链接头.(如果他们不想使用HTTP位置标头,他们甚至可以将自引用链接放入HTTP链接头.)
我不想咆哮,它似乎只是某种"重新发明轮子".它似乎也是非常有限的:如果你只是使用HTTP位置/链接头,那么你在HTTP接受头中询问JSON,XML或其他什么并不重要,你会获得关于你的资源的有用的元信息HEAD请求,如果您使用JSON API,HAL或JSON Hyper-Schema,则不包含链接.
这是我们第一次在我们的项目中使用 JSON API,根据他们网站上的规范,这是常规 JSON API 响应的样子
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
{
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON API paints my bikeshed!",
"body": "The shortest article. Ever.",
"created": "2015-05-22T14:56:29.000Z",
"updated": "2015-05-22T14:56:28.000Z"
},
"relationships": {
"author": {
"data": {"id": "42", "type": "people"}
}
}
}],
"included": [
{
"type": "people",
"id": "42",
"attributes": {
"name": "John",
"age": 80,
"gender": "male"
}
}
]
}
Run Code Online (Sandbox Code Playgroud)
我们不确定,数据中的属性是否应该始终是平面的,或者属性也可以包含嵌套对象,例如位置
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON API paints …Run Code Online (Sandbox Code Playgroud) 我正在使用来自SFG WorldCup API的 JSON 数据。
我需要做的是找到给定球队在给定比赛中的最新进球。为此,我需要按attribute数组中每个元素(即属性的属性)中的键值进行排序away_team_events。
让我举例说明。
以下是正在进行的(在撰写本文时)法国对阵瑞士的法国比赛的 JSON 示例。
"away_team_events": [
{
"id": 276,
"type_of_event": "goal",
"player": "Giroud",
"time": "17"
},
{
"id": 277,
"type_of_event": "goal",
"player": "Matuidi",
"time": "18"
},
{
"id": 278,
"type_of_event": "penalty-wrong",
"player": "Benzema",
"time": "32"
},
{
"id": 279,
"type_of_event": "goal",
"player": "Valbuena",
"time": "40"
},
{
"id": 281,
"type_of_event": "substitution-in",
"player": "Pogba",
"time": "63"
},
{
"id": 282,
"type_of_event": "substitution-in",
"player": "Koscielny",
"time": "66"
},
{
"id": …Run Code Online (Sandbox Code Playgroud) 我尝试实现一个支持 JsonApi 标准的 ASP.NET Web Api 控制器(http://jsonapi.org/主要由 Ember.js 使用)
URL 可能包含破折号。但是 C# 代码中对应的方法名可能不包含破折号。
我的javascript尝试发布到
http://localhost:50000/jsonapi/activity-exercises
Run Code Online (Sandbox Code Playgroud)
但是我无法实现可以接收该请求的端点。我试过了:
[HttpPost]
public HttpResponseMessage ActivityExercises([FromBody] ActivityExerciseEntry value)
{
// ...
Run Code Online (Sandbox Code Playgroud)
理想情况下,应该有一个属性添加到方法中,以在 URL 中指定映射的操作名称。这种属性存在吗?
我的路线图如下所示:
public static void RegisterRoutes(RouteCollection routes)
{
routes.MapHttpRoute("EmberJsonApi", "jsonapi/{action}/{id}", new { controller = "JsonApi", id = RouteParameter.Optional });
routes.MapHttpRoute("DefaultApi", "api/{controller}/{id}", new { id = RouteParameter.Optional });
}
Run Code Online (Sandbox Code Playgroud) 我正在开发一个带有Rails后端的Ember应用程序,使用优秀的JSONAPI :: Resources gem来公开我的数据.
我想利用来从我的后端的记录store.findRecord,store.query等,而侧面加载一定的关系.JSONAPI :: Resources 支持 规范的这一部分,但我无法弄清楚如何使Ember Data包含?include=...请求URL中的参数.
如何指示Ember Data(2.2.0)在获取资源时要求后端包含关系?
假设我有一个支持创建新消息的端点。我避免在后端创建两次相同的消息,以防用户尝试按按钮两次(或者前端应用程序行为异常)。
目前,对于重复操作,我的服务器正在响应 303 see other 指向先前创建的资源 URL。但我发现我也可以使用 302 发现。哪一个看起来更合适?
请注意,重复避免策略可能更复杂(例如,对于约会,我们将检查发布的约会是否在现有约会的一小时内)
我有一个控制器方法drop_down_values,在其中选择一组值并以 json 响应,使用序列化器构建对象。我正在使用 FastJson Api。我想知道,如何访问序列化器中控制器中存在的其他变量。
def drop_down_values
@drop_down_values = IndustrySectorList.all
@values = @drop_down_values.pluck(:industry_sector)
render json: DropDownValueSerializer.new(@drop_down_values).serialized_json
end
Run Code Online (Sandbox Code Playgroud)
我需要@values在序列化器中使用该变量。我如何将其传递给序列化器?我无法在序列化器中直接访问此变量。
序列化器:
class DropDownValueSerializer
include FastJsonapi::ObjectSerializer
attributes :id
end
Run Code Online (Sandbox Code Playgroud)
堆栈和版本 -
serialization ruby-on-rails json-api ruby-on-rails-5.2 fastjsonapi
json-api ×10
json ×4
rest ×3
api ×2
ember-data ×2
ember.js ×2
api-design ×1
c# ×1
django ×1
duplicates ×1
fastjsonapi ×1
hal-json ×1
hateoas ×1
python ×1
sorting ×1