[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-taxii] Open Questions on RC1
|
Yeah I was thinking about this last night after I got home and I’m coming around to this approach. What changed my mind is that many collections will be very dynamic, and paging using limit/offset
will fail when you have a lot of new data in between paginated requests. Using the link header approach allows offset/limit, but also allows you to do an index or date based approach so you don’t get duplicate records in dynamic collections. Example of failure of offset/limit: Records 15-1 exist, sorted by date added w/ most recent first: 15, 14, 13, 12, 11, 10 …. 1 I request 5 records: offset=0;limit=5 and get 15, 14, 13, 12, 11 Records 16 through 20 are added to the beginning of the collection: 20, 19, 18, 17, 16, 15, 14 … 1 I request the “next 5 records”: offset=5;limit=5 and get 15, 14, 13, 12, 11 again (because 5 records were added to the beginning) ID-based pagination fixes this problem (where you request the start record by ID rather than an offset). But, rather than standardize on that, the Github approach that Greg pointed to allows
for either. To the client it’s all invisible, you just get back links that you can to follow and don’t really care what happens behind the scenes. Clients can still control page size by using per_page. John From:
<cti-taxii@lists.oasis-open.org> on behalf of Greg Back <gback@mitre.org> I’m ok with this, but I really like GitHub’s approach of building the URLs for you in the “Link:” header, and telling you not to build URLs yourself: https://developer.github.com/v3/#link-header From:
<cti-taxii@lists.oasis-open.org> on behalf of "Coderre, Robert" <rcoderre@verisign.com> I agree with Allan regarding paging. Server should dictate the paging. For example, our API returns the following fields with every call: "total_size": 84604, "page": 1, "page_size": 25, "more": true By default, page size is 25 up to a max of 200, which is set by a page_size parameter. To retrieve extra pages, increment the page counter ‘page’ by 1 until ‘more’ returns
false. From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Allan Thomson My suggestions inline. From:
<cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> All, We have been working through RC1 and processing as many of the comments and suggestions that we can. One of the comments that we received is that we really need to do Pagination in this first release. Sergey
has kindly submitted some suggestions to solve this. We have a few questions though, that we need you all to decide on: 1) Should the client be allowed to do its own pagination, aka, should it be allowed to set its limit or should the Server determine that? Another option is should the limit just be defined in the spec.? a)
What happens when the client asks for 1000 records and the server is only willing to give 100, should the server return an error, should it fulfill the request up to a 100 and then give a hint in say the
HTTP Header that the "limit" is "100", or should it be done a different way. AT: Server should provide hint in the negotiation of what the max size that it supports is. Secondly if a client asks for a size larger than the server supports then the server should
respond with its limit and status message that indicates the content requested was limited based on server limits. Another thing we came across that is that the definition of a list in TAXII was not the same as STIX. Meaning, TAXII allowed empty lists. We are proposing that this be changed. Does anyone
have any issue with that? What this would mean is that you would get an HTTP 204 (No Content) back instead of an empty list. AT: No issue. In section 4.5, the Manifest Resource, we are also proposing that we remove the "last_modified" property and just say that the "versions" property MUST be sorted in ascending order. Does anyone
have an issue with this? AT: Suggest we use the same terminology as defined in STIX schema (which uses modified) and therefore we should stick with modified term and not use version. Bret |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]