我们目前正在为我们的iOS应用评估JSONModel,并且非常喜欢它。问题是,我们必须处理OData API,它往往会使某些地方的事情过于复杂。例如,当获取实体列表时,我能想到的所有API都会返回这样简单的东西:
{
items: [
{ id => 123, name => 'foo' },
{ id => 124, name => 'bar' },
{ id => 125, name => 'baz' },
]
}
不幸的是,OData给了我更多这样的东西:
{
d: {
results: [
{ Item => { id => 123, name => 'foo' } },
{ Item => { id => 124, name => 'bar' } },
{ Item => { id => 125, name => 'baz' } },
]
}
}
“d”是我最不重要的问题(因为我们可以解析它)。但我无法弄清楚如何处理列表中的每个项目都包含在项目类型为键的哈希中这一事实,因此通过NSArray的JSONModel关系不起作用。我可以为我的Item定义JSONKeyMapper,如下所示:
@"Item.id" : @"id",
@"Item.name" : @"name"
但是当有多个项目时,OData标准仅将项目包装在自己的哈希结构中。例如,当从OData API中获取单个项目时,我得到(正如预期的那样):
{
d: {
results: {
id => 123,
name => 'foo'
}
}
}
: - (
有关如何处理此事的任何想法?之前有人建议两个主要的OData iOS客户端之一:不幸的是,他们似乎都不支持和/或过时,包括微软列出的官方版本。
答案 0 :(得分:1)
可能会回答您的问题的一个FYI:
您发布的JSON是OData的旧JSON格式(现在通常称为“JSON Verbose”)。事实上,当OData被OASIS正式标准化时,它就会彻底消失。
我们替换这种旧格式的部分原因正是您在这里遇到的:它很难消耗。
如果您正在谈论的OData服务支持OData协议的第3版,则要求“application / json”应该返回新的JSON格式。你可以更明确地要求“application / json; odata = minimalmetadata”。新的JSON格式没有任何“d”包装,其结构类似于您在问题顶部所期望的JSON。
如果您正在与之交谈的服务不支持V3,并且您自己无法控制服务,我会将其留给其他人来帮助解决您需要解决的问题。如果您确实控制了服务(或者可以唠叨那个人),我建议更新服务以支持V3。
答案 1 :(得分:0)
在理解为什么OAuth能够完成您所描述的内容时,没有深入细节,以下是我将采用的方法。
无论如何,我的观点是你不需要一次性解析所有内容。您也可以在首次访问属性时使用自定义访问器方法执行此操作。或者如果你真的想做一些时髦的设置,你也可以实现一个自定义的initWithDictionary:error:方法,并在实例初始化结束时添加一些额外的逻辑。