How to prevent multiple RKResponseDescriptors from matching?

Question

I am using RestKit 0.20.0rc1 in an application that uses 2 objects:

• "Note" (NoteClass).
• "Set" (SetClass), which contains a collection of notes.

I have the following 2 response descriptors (among other things):

// GET /sets/:setID/notes // Get a set notes. Response looks like this: // {"notes": [ (array of NoteClass dictionaries) ], // ...more stuff... // } RKResponseDescriptor *noteResponseDescriptor = [RKResponseDescriptor responseDescriptorWithMapping:[NoteClass rkEntityMapping] pathPattern:@"/sets/:setID/notes" keyPath:@"notes" statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)]; [objectManager addResponseDescriptor:noteResponseDescriptor]; // GET /sets/:setID // Get information about a set. Response looks like this: // {"name": "My Set", // "numNotes": 3, // ...more stuff... // } RKResponseDescriptor *setResponseDescriptor = [RKResponseDescriptor responseDescriptorWithMapping:[SetClass rkEntityMapping] pathPattern:@"/sets/:setID" keyPath:nil statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)]; [objectManager addResponseDescriptor:setResponseDescriptor]; 

When I request "/ sets /: setID / notes", noteResponseDescriptor matches (expected). However, setResponseDescriptor also matches (unexpectedly). I believe this is because the response descriptor path template matches the substring "/ sets /: setID", and since the key path is zero. As a result, when I make a request, the returned RKMappingResult contains an array of NoteClass objects (expected) and one empty SetClass object (unexpectedly).

How to prevent setResponseDescriptor from matching this endpoint of notes? I cannot add the key path to setResponseDescriptor (yet), so I prefer a solution that allows me to say something like "match / sets /: setID $", where "$" indicates the end of the URL.

Answer 1

Turns out there is now a way to prevent multiple matches for your example (see discussion here ).

While the solution is on the way, you have several options for this:

• Modify the API URLs so that they are not ambiguous.
• Check the type of result objects displayed and discard any unexpected objects
• Modify [RKResponseDescriptor matchesPath:] as suggested in the discussion.

Each decision is wrong in its own way.