尝试使用 RestKit 发出 POST 请求并将响应映射到核心数据 [英] Trying to make a POST request with RestKit and map the response to Core Data

问题描述

我正在使用 RestKit 框架，我想发出一个 POST HTTP 请求.响应是 JSON.我想将 JSON 响应自动放入 CoreData 中.

I am using RestKit framework and i want to make a POST HTTP request. The response is JSON. I want to put the JSON response automatically in the CoreData.

我不知道要调用什么方法来发出请求.我知道我应该使用 RKObjectManager 的方法，但我没有找到合适的方法.

I don't know exactly what methods to call to make the request. I know that I should use RKObjectManager's methods but I didn't find the right one.

我发现了这个方法 postObject:delegate: 但我不知道将什么对象作为参数传递.我也在文档中找到了这个方法:loadObjectsAtResourcePath:usingBlock: 但我不能使用它，因为它告诉我:

I found this method postObject:delegate: but I don't what the object to pass as parameter. I also find this method in documentation: loadObjectsAtResourcePath:usingBlock: but I can't use it because it tells me:

No visible @interface for 'RKObjectManager' declares the selector 'loadObjectsAtResourcePath:usingBlock:'

推荐答案

Vlad - 首先，让我们为您的原始问题找到答案:

Vlad - First off, let's get an answer in place to your original question:

我假设您使用的是 RestKit 0.20.0，但熟悉 RestKit 0.10.x API 并且正在查阅过时的信息.您应该转向的第一个位置是 RKObjectManager.h —— 标头始终是最新的，并将包含有关哪些方法可用的文档.接下来，您始终可以在最新的 API 文档站点上查看根据源代码构建的最新文档.

I assume that you are working off of RestKit 0.20.0, but are familiar with the RestKit 0.10.x API's and are consulting outdated information. The first place that you should be turning is to RKObjectManager.h -- the headers are always going to be up to date and will contain docs about what methods are available. Next, you can always view the latest documentation built from the source code on the latest API docs site.

您在这里要做的是创建一个RKObjectRequestOperation:

What you want to do here is create an RKObjectRequestOperation:

NSDictionary *dictionary = @{ @"firstParam": @(12345), @"secondParam": @"whatever"};
NSMutableURLRequest *request = [objectManager requestWithObject:nil method:RKRequestMethodPOST path:@"/whatever" parameters:parameters];
RKObjectRequestOperation *operation = [objectManager objectRequestOperationWithRequest:request success:^(RKObjectRequestOperation *operation, RKMappingResult *result) {
    NSLog(@"Loading mapping result: %@", result);
} failure:nil];

如果您尝试定位核心数据，那么您需要使用 RKManagedObjectRequestOperation 和 managedObjectRequestOperationWithRequest:success:failure:.RestKit Github 站点上的 README.md 和标题文档中还有其他示例，单元测试中还有大量代码供参考.

If you are trying to target Core Data, then you'll want to use RKManagedObjectRequestOperation and managedObjectRequestOperationWithRequest:success:failure:. There are additional examples available in the README.md on the RestKit Github site and in the header docs and there is a metric ton of code in the unit tests for reference as well.

接下来，回应 JRG-Developer 的评论:

Next, in response to the comments from JRG-Developer:

咳咳，出于多种原因，这是一个非常糟糕的答案.(免责声明:我是 RestKit 的主要开发者)

Ahem, this is a really terrible answer for a number of reasons. (Disclaimer: I am the principal developer of RestKit)

首先，您使用的是哪个版本的 RestKit?如果您使用的是最新版本(即在 0.20.x 预发布系列中)，则加载对象集合的方法已被替换为更好的名称:getObjectsAtPath:.这在两个 API 文档(按路径提出请求) 和 0.10 到 0.20 迁移指南.

First of all, what version of RestKit are you using? If you are using a recent version (i.e. in the 0.20.x pre-release series) then the methods for loading collections of objects have been replaced with better names: getObjectsAtPath:. This is fully documented in both the API documentation (Making Requests by Path) and in the 0.10 to 0.20 migration guide.

我怀疑这里的原始问题源于引用过时的文档和最近的代码.

I suspect that the original issue here stems from referring to outdated documentation along with recent code.

接下来，一旦您真正了解了该库，您推荐的技术堆栈远设置和使用起来要复杂得多，以完成与 RestKit 为您提供的相同的事情.

Next, the stack of technologies you are recommending is far more complicated to setup and use to accomplish the same things that RestKit provides for you once you actually understand the library.

让我们一点一点地看:

1. AFNetworking

• AFN 是一个很棒的轻量级库，用于执行异步网络操作.如果您将 RestKit 视为包含许多用于实现客户端 API 的工具的工具箱，那么 AFN 就是锤子.
• 我非常尊重 AFN，在 RestKit 0.20.x 中，我们放弃了老化的自制网络库，转而支持 AFNetworking，因为它的设计优于自 iOS 3.0 以来一直存在的 RestKit 自定义网络堆栈.然而，在没有深入了解 Core Data 并自己实现大量同步代码的情况下，仅靠 AFN 并不能为您提供足够的火力来完全实现与 Core Data 集成的 API.
• RestKit 的对象映射系统为您提供了一个高性能、一致的 API，用于配置这些同步活动，而不是您自己实现它们.这可以实现一些重要的性能优化，我将在稍后返回.

JSONKit

• JSONKit 是另一个我非常重视的库，但它可能不值得您花时间.与 NSJSONSerialization 相比，JSONKit 的 JSON 解析速度更胜一筹——但只有几毫秒.
• 作为为广泛部署的应用程序实现大型 API 客户端的人，我可以告诉您，您的时间不会花在 JSON 序列化/反序列化上，而是花在反序列化后处理 JSON 的代码上.

• JSONKit is another library that I hold in high regard, but it's probably not worth your time. When compared to NSJSONSerialization, the JSON parsing speed of JSONKit is superior -- but only by milliseconds.
• As someone who has implemented large API clients for widely deployed apps, I can tell you that your time is not going to be spent in JSON serialization/deserialization, but in the code that processes your JSON once it has been deserialized.

MagicalRecord

• MagicalRecord 是一个 Core Data 便利库，它为 Core Data 中的现有功能提供速记访问器.一旦你深入了解实现 HTTP 到核心数据同步方案真正需要的细节，它不会改善你的生活.您的问题将与没有与核心数据获取请求的语法过于冗长、维护对托管对象上下文的引用或获取核心数据堆栈设置不方便有关.莉>

• MagicalRecord is a Core Data convenience library that provides shorthand accessors for existing functionality in Core Data. It is not going to improve your life once you get into the nuts and bolts of what it really takes to implement an HTTP to Core Data synchronization scheme. Your problems will have nothing to do with the syntax of Core Data fetch requests being too verbose, it being inconvenient to maintain a reference to your managed object context, or with getting the Core Data stack setup.

那么让我们暂时讨论一下实现将 API 建模为 Core Data 的 iOS/OS X 应用程序的实际问题是什么:

So let's talk about what the real problems are with implementing an iOS / OS X application that models an API into Core Data for a moment:

1. 异步访问
   • 您将遇到的第一个问题是您习惯于以同步的、面向主线程的方式进行编程，但现在您需要触发一个加载 JSON 的 AFNetworking 请求，然后将其加载到您的对象中模型.没问题，只需等待 AFJSONRequestOperation 在成功块中回击您并更新核心数据，对吗?错误的.现在您正在异步执行网络 I/O，但随后在主线程上执行更新数据模型的 CPU 密集型任务.现在您的应用程序性能很差，您不知道该怎么办.你如何将同步移动到后台?完成后如何通知 UI?

1. Asynchronous Access
   • The first problem you are going to run into is that you are used to programming in a synchronous, main thread oriented way, but now you need to fire off an AFNetworking request that loads your JSON, but then load it into your object model. No problem, just wait for the AFJSONRequestOperation to hit you back in the success block and update Core Data, right? Wrong. Now you are doing your network I/O asynchronously, but then doing the CPU Intensive task of updating your data model on the main thread. Now your app performance sucks and you don't know what to do about it. How do you move that synchronization into the background? How do you notify the UI once its done?

• 遇到错误时会发生什么?当您遇到网络错误时，您会怎么做?当网络操作完成，但在访问 Core Data 时遇到错误，你会怎么做?你打算怎么处理?你打算把这个错误处理代码放到你所有的控制器中吗?您将如何封装所有这些逻辑?
• 您将如何处理服务器返回的错误?

• 好的，现在您已经加载了您的 JSON，并且您想将其放入 Core Data.伟大的.您将如何区分商店中的现有对象与需要创建的新对象?
• 如果你弄错了，你现在有重复的对象.
• 如果您做对了，但从主线程上下文中执行此操作，您的 UI 会被阻塞并且您的性能会很差.
• 如果您做对了，但在后台线程上执行此操作，您可能会遇到并发问题.
• 如果您做对了，但是使用获取请求访问持久存储以识别您的唯一对象，那么您现在就会遇到性能问题.

• 一旦您将数据集与服务器同步，您将如何处理从本地存储中删除服务器上不再存在的死对象?

• 正如我在此咆哮的前几部分中提到的那样，所有道路最终都会导致性能.如果您实际上正在尝试构建可以在大规模范围内工作并取悦用户的东西，那么您将不得不应对严重的性能问题.头晕目眩.

一旦您的应用程序成功，您将不得不应对许多其他问题，包括可测试性、可维护性等.您对这些事情有多少考虑?

There are a number of additional problems you will have to contend with once your application is successful, including testability, maintainability, etc. How much are you thinking about these things?

我想我的主要观点是(从我的角度来看)太常见了，以至于无法听到花生画廊发出关于如何解决基本工程问题的疯狂欢呼或嘲笑.现实情况是，具有基本复杂性的问题的解决方案将有一个相对于所处理问题的学习曲线.

I guess my main point here is that is (from my perspective) far too common to hear insane cheering or jeering coming from the peanut gallery about how to tackle fundamental engineering problems. The reality is that the solution to problems with essential complexity will have a learning curve that is relative to that of problem being approached.

与尝试解决一个更大但更有趣的问题相比，采用离散的功能切片并确定令人满意的解决方案要容易得多.

It is far, far easier to take a discrete slice of functionality and nail down a satisfactory solution than it is to try and approach a larger, but more interesting problem.

但这并不意味着您将通过将一堆您听说过的库提供更好的问题子集实现而不是解决聚合问题的更大方法来生成更强大的解决方案.

But that does not mean that you are going to produce a more robust solution by lashing together a bunch of libraries that you have heard provide nice implementations of a subset of a problem than a larger approach to the aggregate problem.

如果 RestKit 比 RestKit 好得多，为什么没有人开源他们自己的 AFN/JSONKit/Core Data/MagicalRecord mashup 并将其吹走?

Why hasn't anybody Open Sourced their own AFN/JSONKit/Core Data/MagicalRecord mashup and blow RestKit out of the water if they are so much better than RestKit?

我担心清醒的事实是:事情没那么容易.

I'm afraid that the sober truth is: it just ain't that easy.

干杯！

这篇关于尝试使用 RestKit 发出 POST 请求并将响应映射到核心数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！