I’m working to import and export data into Core Data from a web API.
The web API that i’m interfacing with doesn’t have consistent naming with itself, and certainly doesn’t match the naming conventions that i’d use for attributes in my core data model. (I don’t have control over changing the API conventions).
To illustrate the issue, in one api call the data for a contact might look something like this :
"rows": [
{
"name": "Bob",
"group": "Testing Group A",
"email_address" : "bob@fakedata.com"
}
]
And in another different call that still returns contacts it might look something like this :
"rows": [
{
"Name": "Bob",
"group_name": "Testing Group A",
"Email" : "bob@fakedata.com"
}
]
Notice the small differences in the key naming? In the past, i’ve resolved issues like this by having a “mapping” for each API call. The mapping is just an NSDictionary that has the key’s of the core data names I use, and the values of the API server keys.
So resolving each of these two calls would require each to have an NSDictionary like the following
dict = @{ @"name" : @"name", @"group" : @"group", @"email" : @"email_address" };
dict = @{ @"name" : @"Name", @"group" : @"group_name", @"email" : @"Email" };
This works pretty well, and it’s certainly one path to solve this problem, but having these mappings in every API call isn’t very elegant, and certainly is poor design for code maintainability.
So the real question here is : does anyone have a better solution for managing the mapping of web api’s to Core Data? Obviously having a well written web API is the ideal solution, but even mapping well written API’s can have minor differences (For example, core data requires attributes to begin with a lowercase letter).
My proposed solution is to add the mappings into the core data attribute under the “User Info” (attached image below to see example), but i have zero experience using this feature of attributes, and I don’t know if there is a way better option that i’ve overlooked. Thanks for any help.

Additional Notes : Yes, i’ve used Restkit extensively, and it does have convenient mappings (similar to how I’ve explained using an NSDictionary above). But for this project, i’m eliminating dependency on such a framework that I don’t have control over, and don’t completely understand. I’m pulling this data in with a simple NSURLConnection.
update
If you go down this route (which has been very nice btw, the accepted answer helped a lot). I recommend not using the key word “map” simply because it’s not the default. Use “key” instead because this doesn’t require making two edits to the user info field. For my particular project there are many mappings and this has been annoying. Too late to change now, but learn from my mistake.
Wow, that is one screwed up web API.
Your suggested approach is more or less how I’d deal with it. But instead of having multiple
mapXkeys, I’d use a singlemapkey whose value was a comma-separated list of mappings. In this case, the keymapwould have a value ofCompany,Company_Name,company. That way you read one known key instead of repeatedly testing to see if the next one exists. You can easily convert the comma-delimited list to an array by usingNSString‘scomponentsSeparatedByString:method.A different approach would be to put all this in a property list that you can read at run time. That would be effective but I prefer keeping all of the information in one place, and the user info dictionary is ideal.
As an aside, for what it’s worth, Core Data does not require that attribute names begin with a lower case letter. However, Xcode’s data model editor does enforce that restriction– forcing you to follow a guideline that you might well have cause to violate. If you’re so inclined, you can edit the model file by hand and change attribute names to start with upper case letters. The file is XML, and if the tool compatibility setting is Xcode 4.0 or higher it’s very easy to read. Once you do this you can even use Xcode’s built-in class generation with those attributes.