A difficulty is that you can't remove options once they are published. A second problem is that you don't want your API to leak the underlying implementation or

A difficulty is that you can't remove options once they are published. A second problem is that you don't want your API to leak the underlying implementation or it will be brittle. But that doesn't mean that you shouldn't allow parameters - both examples given were a cop-out really. I've had good results with basic parameters - date ranges, index ranges for paging, ordering by a couple of important and relevant fields (could well include some kind of computed value like 'hotness'), and probably most importantly - a query parameter (search algorithm being blackboxed in API). If you need many more params, it may be a sign that the underlying resource is becoming overcomplex and can be decomposed - I've made applications where the API interfaces were completely uniform across resources, which worked out really well and encouraged takeup (the most important measure for an API). The other main question is whether to allow the caller to request which fields to return (cache-filling and complexity vs bandwidth).