|
OK you got me. Here are my thoughts:
What additional information do you need to understand the design?
- Is there some explanation for what the group concept is supposed to represent? I guess I get it conceptually, but it’s not clear to me what use case it’s solving vs. just running separate instances. In other words, why do groups need to be defined
by TAXII?
- Do you plan to prescribe caching strategies or will it be up to individual servers to implement that?
For your use case, does it contain anything really bad/unworkable?
- Should the content type be set at the channel level or the message level? It seems like you might want to have several different types of content on the same channel. If you set it at the message level, this field can go away.
- This doesn’t seem targeted at a request/response use case. That’s not really a problem, doing both that and pub/sub in the same spec would get complicated, but I figured it was worth calling out.
- Are you planning to support update and destroy (PUT and DELETE)? Obviously renaming channels would be complicated and have weird side effects given the name is in the URL, but changing permissions for existing channels is probably a requirement.
- The messages POST request seems to say you’ll create one message at a time, but the GET request lets you get multiple messages at once. That seems inconsistent. Maybe a POST should let you create multiple? That would cut down on the number of
individual HTTP requests required (assuming clients queue and send)
If you’re an implementor, could you implement it?
Yeah, as far as I can tell.
Other important questions to ask
- Did you consider having the server auto-assign identifiers for channels and groups? I haven’t thought through it a ton and don’t have any problems with names but it’s an option.
- Did you consider message-level permissions?
- How about message level TTLs? I might want some indicators to live longer than others, for example.
John
All,
Since it worked well last time, I’ll threaten to interpret your silence as overwhelming agreement that the proposed REST API looks pretty awesome.
As you review the REST API, please think about the following:
·
What additional information do you need to understand the design?
o
If you have no context for what it is or why it’s being proposed, ask some questions! You can ask them to Bret and I directly and we’ll
anonymously post them.
·
For your use case, does it contain anything really bad/unworkable?
·
If you’re an implementer – could you implement it?
·
Are there other important questions to ask?
Thank you.
-Mark
Given the strawman MTI discussion for using HTTP, the slack channel over the past few weeks has had a very lively discussion about what it would look like if we implemented a RESTful API for TAXII 2.0 on top of
HTTP. As this discussion has started to come to a steady state, we feel that it is important to move it out of Slack and in to the formal email discussion space to see if it holds water and hopeful flesh out further ideas.
If we were to use a RESTful API over HTTP for TAXII 2.0, this would not represent a radical change form TAXII 1.1, but rather, IMO, a natural evolution of the TAXII 1.1 services concept. I also believe this will
enable us to build a foundation from what future versions of TAXII, beyond 2.0, can iterate and add functionality.
The current mock up on the HTTP REST API can be found here:
NOTE: remember anyone that wants to join our Slack channel, please let us know, just be mindful that it can be very high volume.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
|