[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
large categories documents
I am wondering about large categories documents. If a Collection is large, its Members can be categorized many ways, resulting in a large number number of atom:category elements in the app:categories element.
First, I realize this element can be / should be offered as its own resource, but it doesn't prevent the size of the document from being a) too big to generate and b) too big to parse. I guess this situation could happen with virtually any resource, even a Member/entry.
What to do?
I would like to be able to offer it as an application/atom+xml;type=feed, but it seems it is mandated to be application/atomcat+xml. So, what about putting a <atom:link rel="next"/> into that document and paging the feed. Would that be "atompub" compatible, or even a good idea? Moderately extensive programming has to be done to support paging on any given resource, so it is worth asking what the 'right' approach is. I suppose REST even lets me declare a cut off and truncate the size at some arbitrary point, but that does not seem like a good way to build trust with the customer :-). Maybe
a combination of the two, where the application/atomcat+xml size is "governed"/limited, and an alternate is offered as a feed?
Any advice considered!