GET, POST and render URLs

[Subbu Allamaraju <subbu@bea.com>]

During last week's interfaces call, we discussed the question of GET, 
POST and render URLs. To follow up this discussion, I would like to make 
a few comments.

At a semantic level, I see two different issues here.

a. Mapping GET to getMarkup request, leaving POST for interactions.

b. Supporting render URLs via getMarkup.

AFAIR, it was the second issue that prompted the first one. I think we 
can make some progress if we treat these as two seperate issues.

On the first question, I don't think that the protocol ought to specify 
whether a user-agent's GET request be mapped to getMarkup (or 
getResource) or not. The decision should be left to the Consumer. I 
don't see this as breaking HTTP or the W3C arch recommendations. We're 
just letting the Consumer make the choice.

The second question addresses a hole in the current specification. 
Currently, WSRP only supports render URLs whose parameters are known at 
the time of generating the markup. This prevents a portlet from 
capturing request data via a form or a URL created dynamically in the 
browser.

To support a render URL, Consumers currently resort to a 
performBlockingInteraction, and this has several side effects. 
Performance is definitely one concern. But my main concern is the 
mapping of semantics. For instance, the pbia would cause new nav state 
which would replace the current nav state, and that's the not the intent 
of render URLs.

I suggest that we add form parameters to getMarkup. This would allow the 
consumers to correctly implement render URLs.

Regards,

Subbu