Designing good API is an art. Good API is appreciated even after time passes. In my opinion, there should be no general bias on the abstract-concrete line. Some parameters can be as concrete as days of the week, some require to be designed for extensibility (and it is quite stupid to make them concrete, eg, part of function names), yet another may go even further and in order to have elegant API one needs to provide callbacks or even domain specific language will help to fight complexity.
There are rarely new things happening under the Moon. Take a look at the prior art, especially established standards and formats (e.g., many things can be modelled after feeds, event descriptions were elaborated in ical/vcal). Make your API easily additive, where frequent and omnipresent entities are concrete and envisioned extensions are dictionaries. There are also some well-established patterns for dealing with specific situations. For example, handling HTTP request (and similar) may be modelled in the API with Request and Response objects.
Before designing API, brainstorm on aspects, including those, which will not be included, but you must be aware of. Examples of such are language, direction of writing, encoding, locale, timezone information and the like. Pay attention to places where multiples can appear: use list, not single value for them. For example, if you are desing API for videochat system, your API will be much more useful, if you assume N participants, not just two (even though your specs at the moment are such).
Sometimes, being abstract helps to reduce complexity drastically: even if you design a calculator for adding only 3+4, 2+2, and 7+6, it may be much simpler to implement X+Y (with technically feasible bounds on X and Y, and include ADD(X, Y) to your API instead of ADD_3_4(), ADD_2_2(), ...
All in all, choosing one way or another is just a technical detail. Your documentation should describe frequent use cases in a concrete manner.
Whatever you do on the data structure side, provide a field for an API version.
To summarize, API should minimize complexity when dealing with your software. TO appreciate the API, the level of exposed complexity should be adequate. Deciding on the form of the API depend a lot on the stability of the problem domain. Thus, there should be some estimation on which direction the software and it's API will grow, because this information may affect the equation for complexity. Also, API desing is there for people to understand. If there are any good traditions in the software technology area you are in, try not to deviate much from them, as it will help understanding. Take into account for whom you write. More advanced users will appreciate generality and flexibility, while those with less experience may be more comfortable with concretics. However, care for the majority of API users there, ie those in between beginners and experts.
On the literature side I may recommend "Beautiful Code" Leading Programmers Explain How They Think By Andy Oram, Greg Wilson, as I think beauty is about perceiving hidden optimality (and suitability for some purpose).