It’s just data

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:



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.

Posted by Mark at

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 at

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...

Posted by Mark at

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...

Posted by Sam Ruby at

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.

Posted by Phil Ringnalda at

Add your comment