In processing a
comment API request,
I may end up
grabbing
excerpts,
formatting,
etc. I can also
spell
check. Would there be interest in a variant of the
comment API which simply returns back what would have been
posted instead of actually doing it?
It seems to me that there are the following options for
implementing this API:
Add an optional element within the RSS item itself indicating
that a preview is desired.
Add an element outside the RSS item but inside the HTTP
body.
Add a HTTP header.
Change the resource (i.e., URI) to which such requests are
posted.
One thing I think is important is that such an option not
be ignored. In other words, I presume that a client would
prefer a failure (HTTP status and/or SOAP fault) than to have the
request actually processed. Unless somebody sees something I
don't, that reduces the options to two: SOAP headers with
mustUnderstand
attributes have this semantic, and clearly routing to a different
URL can be presumed to do this effectively.
Suggestions?
In the interests of keeping things as simple as possible, and not causing discontinuities for people who have implemented and deployed this RFP in the past few minutes, I recommend supporting all of those possibilities. Also, add a similar parameter saying that the request is a comment; make it different enough that it's possible to specify both, but document that you shouldn't do that. But don't document which is the default implementation. Also, add the RSS element in the core namespace, and use a randomized precedence order to resolve conflicts.
Also, don't be surprised when people start using your service as a free REST-based spell-checker, since very few people actually want to post comments to your site, but lots of people want to spell-check stuff.
Mark, you seem to be in rare form this morning. ;-)
As to the potential abuse of the spell checker functionality, if this becomes a problem, then I'll revert back to only making spell check available to registered subscribers. As the functionality is available for free anyway, I don't expect there to be an issue...
Sam, never underestimate the will of the f***ing freeloaders of the world.
No doubt this conversation violates one or more of Andy's patents. I wonder how long it will take him to show up here demanding payment. I wonder how well that could be automated with, oh, say, a Comment API.
I wonder whether this API will promote comment spam. Auto-discoverable anonymous posting services. Hmm...
Bah. I can deal with Andy. I get comment spam today with a simple HTML form. The path is clear: first registration, then ultimately mydentity.
You want to know what does concern me right now? My intended syndication format exactly matches the comment API format. Even with a registration scheme in place, all that would be required is a throwaway hotmail account to send our server chasing its tail...
You're going to syndicate with a link element, right? If the Comment API uses link as "the URI that most closely represents the person commenting", then just banning comments with a link any deeper than intertwingly.net/blog/ ought to prevent your comments from commenting on themselves. Or at least make it no easier than flooding you through any other method.