There is no general answer to your question, but let me provide one to your example to point out some principles that generally apply.
Note: I shall henceforth speak of "interfaces" instead of "protocols", not only because it is arguably more common name for it in other languages, but also because I really mean interfaces in a more abstract way, as in "the definition of how something can be interfaced with".
When designing an interface, you should design it, as if you had no means to implement it yourself, but rather had to rely on somebody else, whom you will only be able to communicate your needs to through your definition.
If you assume this scenario, you see that you want an interface to be very clear (otherwise the implementation may not be designed to do what you expect) and very easy to implement (otherwise the implementation may fail to do what you expect).
Now in the context where you depend on the service abstracted to the interface you design, you should have been able to make several important decisions, that you shouldn't forward to the implementor to not force them to overstep the single responsibility principle, nor provoke code duplication. Instead, you need to make those decisions and convey them in your method invocation.
In this example, you might have:
- figured out, whether some items can be processed in batch - assuming you expect any advantages in doing so
- been able to filter out duplicates - assuming your system can produce any in the first place
And thus (under both assumptions) your contract with the implementor should be "you must be able to process a batch of unique URLs".
You can hardly transport this contract unambiguously without documentation, but you can try, for example by method names. IMHO receiveDroppedItems is not very expressive, because item is really ambiguous and receive also is in a language based on message passing.
I would call it processDroppedURLs. It's not longer, but it really says what's expected to happen. If I am asked to implement such a method, I think "Oh, ok, so I am expected to process a collection of dropped URLs" (assuming I know what dropped means in that context, I know all I need). Even though the collection's type might be defined to something as vague as NSFastEnumeration, I would expect for...in to yield NSURLs. As for the uniqueness information, I would probably rather put that into the documentation, rather than the method name, because it's not that vital.
So to summarize: You want clean, concise, almost minimalistic interfaces with expressive method names, that create abstraction barriers between the current client scope and the abstracted service scope, which are clear and simple from both sides.
