RFP: Preview API
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?
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.
Posted by Mark at
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...
Posted by Sam Ruby atSam, 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...
Posted by Mark atBah. 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...
Posted by Sam Ruby atYou'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.
Posted by Phil Ringnalda at
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.
Posted by Mark at