> We still return per_page in our API calls as we have limits on what > the client can request. So although a client my request a page size of > 200 for load management and performance reasons we may only accept > values of 50 (for example).
I quote myself: > and in which case, it should accept a range value, or two values, one for > range beginning and range end. The > gist here being that some clients might find it suitable to fetch more, > others less, and your API should simply > let those clients decide that. Probably up to a certain number of posts, of > course. As for what Ivan suggested, working backwards from what you'll need works, yes, and probably if said API will be consumed first and foremost by JS, then go for that and make changes as you need them should mobiles or whatever come next. I assume you have a budget/time, so that helps that. Oh and about "semantics" in APIs, the fact is an array is a structure where the length equals the number of entities it carries. So turning a collection into an object just so it can carry metadata which can obviously be extracted from this characteristic of the collection doesn't make anything more semantic, but just repetitive. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
