我正在实现JSON API结构的一半（具有下划线属性）。
开发环境的实际状态是：
我使用Active Model Adapter结构请求后端资源和后端响应我JSON API结构。
在Application Serializer中我使用的是JSONAPISerializer。我重写方法：
serializeBelongsTo
keyForRelationship
keyForAttribute
serialize
serializeAttribute
serializeHasMany
为了发展，一切都适合我（Rails的后端与Ember的沟通非常好）。
问题在于Ember CLI Mirage和约定（不确定是否有简单的解决方案，或者我需要再次覆盖此插件中的方法）。
Ember Cli Mirage和测试环境的实际状态：
我正在使用import { JSONAPISerializer } from 'ember-cli-mirage';，然后尝试操作正确的请求，然后将其转换为JSON API格式。
它可以像这样工作：
Ember Adapter（活动模型适配器格式 - 带下划线属性）---> Mirage Serializer应该获取请求（查找在使用关联的测试之前创建的资源），然后使用JSON API格式响应它---> JSON API Serializer可以捕获它并且填写Ember DS。
目前，我缺少将所有情况序列化为JSON API标准（带有下划线属性）的部分
我应该在哪里进行此转换以最小化重写的JSONAPISerializer Mirage Serializer。
我注意到有一些助手，但我有一个问题将这些知识包装在一起（http://www.ember-cli-mirage.com/docs/advanced/route-handlers#helpers）
更新：
后端结构示例：
{
"data": {
"id": "6",
"type": "first_resource",
"attributes": {
"id": 6,
"my_attribute": "my_attribute"
},
"relationships": {
"second_resources": {
"data": [
{
"id": "16",
"type": "second_resource"
}
]
},
"third_resource_other_type": {
"data": {
"id": "1",
"type": "third_resource"
}
},
"fourth_resource": {
"data": {
"id": "1",
"type": "fourth_resource"
}
}
},
"links": {
"fifth_resources": "/api/v1/first_resources/6/fifth_resources"
}
},
"included": [
{
"id": "1",
"type": "fourth_resource",
"attributes": {
"id": 1,
"my_attribute": "my_attribute"
},
"links": {
"sixth_resource": "/api/v1/fourth_resources/1/sixth_resource"
}
},
{
"id": "16",
"type": "second_resource",
"attributes": {
"id": 16,
"my_attribute": "my_attribute"
},
"relationships": {
"eighth_resources": {
"data": []
}
},
"links": {
"seventh_resources": "/api/v1/second_resources/16/seventh_resources"
}
},
{
"id": "17",
"type": "second_resource",
"attributes": {
"id": 17,
"my_attribute": "my_attribute"
},
"relationships": {
"eighth_resources": {
"data": []
}
},
"links": {
"seventh_resources": "/api/v1/second_resources/17/seventh_resources"
}
},
{
"id": "15",
"type": "second_resource",
"attributes": {
"id": 15,
"my_attribute": "my_attribute"
},
"relationships": {
"eighth_resources": {
"data": [
{
"id": "26",
"type": "eighth_resource"
},
{
"id": "24",
"type": "eighth_resource"
}
]
}
},
"links": {
"seventh_resources": "/api/v1/second_resources/15/seventh_resources"
}
},
{
"id": "26",
"type": "eighth_resource",
"attributes": {
"id": 26,
"my_attribute": "my_attribute"
}
}
]
}
UPDATE2
海市蜃楼反应的结构：
data: {
attributes: {
my_attribute: 'my_attribute',
second_resource_ids: [36, 37],
fifth_resource_ids: []
},
id: 11,
relationships: {
third_resource_other_type: {data: null}
fourth_resource: {data: null}
second_resources: {data: []}
},
type: "first_resources"
}
测试资源：
server.create('second-resource', {
id: 36,
first_resource_id: '11',
my_attribute: "my_attribute"
});
server.create('eighth-resource', {
id: 140,
second_resource_id: 37
});
server.create('eighth-resource', {
id: 141,
second_resource_id: 37
});
server.create('second-resource', {
id: 37,
first_resource_id: '11',
eighth_resource_ids: [140, 141]
});
server.create('first-resource', {
id: 11,
second_resource_ids: [36, 37]
});
海市蜃楼的first_resource模型：
export default Model.extend({
third_resource_other_type: belongsTo(),
fourth_resource: belongsTo(),
fifth_resources: hasMany(),
second_resources: hasMany()
});
让我们试着关注一个单一的关系，因为你发布的问题中有很多事情要发生。我们来看看second-resource。
看起来Mirage在QSON：API有效载荷中的second_resource_ids主数据的attributes密钥下发回first_resource。这告诉我幻影认为second_resource_ids是first_resource的一个属性，实际上它是一种关系。
假设您的模型和关系设置正确，您需要调整在Mirage中创建数据的方式。
如果你看看Associations section of the Defining Routes guide，你会看到这样的信息：
Mirage的数据库使用camelCase来处理所有模型属性，包括外键（例如上面例子中的authorId）
现在，你这样做：
server.create('second-resource', {
id: 36,
first_resource_id: '11',
my_attribute: "my_attribute"
});
server.create('first-resource', {
id: 11,
second_resource_ids: [36, 37]
});
但是从Mirage的角度来看，你需要使用camelCase ID，或者只是传递关系，以正确设置它们。像这样的东西：
let firstResource = server.create('first-resource', {
id: 11
});
server.create('second-resource', {
id: 36,
firstResource,
myAttribute: "my_attribute"
});
如果你愿意，你也可以在创建时传入外键 - 只需确保使用camelCase：
server.create('second-resource', {
id: 36,
firstResourceId: '11',
myAttribute: "my_attribute"
});
请记住，属性和外键（如some-attribute与some_attribute或relationship-id与relationship_id之类的内容）的格式化决策是在序列化程序层进行的。在处理Mirage的ORM和数据库时，无论Serializer发出什么格式，您都希望坚持使用camelCase。
有关更多信息，请查看文档中的以下部分：