Here's what I'd expect:
# Post (X)HTML or Atom (entries or feeds) directly
POST /service HTTP/1.1
Host: ...
Content-Type: application/xhtml+xml
Content-Length: nnnn
...
# Response with 200 OK and transformed content
HTTP/1.1 200 OK
Date: ...
Content-Type: application/xhtml+xml
Content-Length: nnnn
...
Or, if the content is URL addressable..
# Get with a querystring
GET /service?url={url of content} HTTP/1.1
Host: ...
# Response with 200 OK and transformed content
HTTP/1.1 200 OK
Date: ...
Content-Type: application/xhtml+xml
Content-Length: nnnn
Obviously the GET approach is optimum.
- James
John Panzer wrote:
I have a use case where I think the Atom syntax works well, but it's not
an APP scenario.
I want to provide a web service which renders arbitrary (X)HTML content
'safe' for rendering on web pages. This would basically mean applying
an element/attribute whitelist filter and also transforming content into
XHTML. It might also provide optional rules for dealing with titles
(e.g., transforming into a plain text approximation) that would be
useful for clients. The motivation here is to allow things like third
party comments in web pages without allowing cross-site scripting
attacks or just bad markup that might destroy the page. The reasoning
for providing a web service is that this kind of thing is only an
approximation and requires constant maintenance and updates as new
attacks appear.
My first thought is to simply provide a custom endpoint which accepts
POSTs of Atom Entries (or even Atom Feeds) and returns the transformed
Atom content with an appropriate HTTP return status. (What success
return status would be most appropriate for this type of transformation
service?) This part just seems too easy -- is there anything else I'm
missing?
Thanks,
John
