[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-taxii] HTTP REST API for TAXII 2.0
|
Based on the conversation so far, I’d like to assert the following: ·
The REST API seems to feel generally right to most of the group (e.g., I didn’t see any comments saying REST was the wrong idea). There are some open
questions that still need to be addressed (listed below in wiki page changes), but we seem to agree on a good portion of topics. ·
We need to dig deeper on the requirements and design for the group concept. What do we hope to accomplish? What’s the best way of accomplishing it? I have updated the wiki page with the following: ·
Added that multiple messages are permitted in POSTs ·
Added an open question about how multiple message dispositions should be handled ·
Added an open question about content negotiation ·
Added an open question about PUT/DELETE requests ·
Added an open question about long polling vs. other options (EventSource) ·
Added an open question about whether the REST API should include features for managing permissions ·
Added an open question about groups I hope this accurately characterizes the current state of the conversation. Did I miss anything? Thank you. -Mark https://github.com/TAXIIProject/TAXII-Specifications/wiki/HTTP-REST-API-for-TAXII-2.0 From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Davidson II, Mark S I had a quick conversation offline w/ John, and I realized there is a terminology collision on HTTP pipelining. HTTP pipelining is the
technique of sending multiple HTTP requests on a single TCP connection [1]. When I used the term pipelining, I meant multiple messages in a single HTTP request or response. Facebook’s ThreatExchange uses the term batching [2], so maybe it’s worth just using
that term? > allowing for multiple content blocks in the POST would be another (simpler to implement) way to do that. John and I were both talking about this concept, just using different terms. I like the EventSource concept – I see it as an alternative to HTTP Long Polling.
I also like exploring the idea of getting rid of the group concept, as long as we can keep all the functionality we need. Thank you. -Mark [1]
https://en.wikipedia.org/wiki/HTTP_pipelining [2]
https://developers.facebook.com/docs/threat-exchange/best-practices/v2.4 From:
cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Wunder, John A. To pull the thread on a couple of those: Groups I can see the use case you’re aiming for, but another option to consider here is not implementing groups in TAXII and just making it clear that you can host multiple TAXII “channel” endpoints. You would lose the
ability of users of the TAXII server to stand up new groups via the standard API, but as a trade-off you wouldn’t have to deal with the groups concept at all in TAXII itself. Just throwing it out there as an idea. Permissions It seems like if you support setting permissions on a channel or group, then you should support modifying them? Pipelining HTTP pipelining is one solution to the connection overhead problem, but just allowing for multiple content blocks in the POST would be another (simpler to implement) way to do that. Implementability I still think this sounds implementable, the two things that seem like the long poles are HTTP pipelining and the EventSource capability (assume this is roughly what you’re talking
about, minus the specific _javascript_ API:
https://developer.mozilla.org/en-US/docs/Web/API/EventSource). TTL Makes sense. John |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]