Availability of parsed parameters in yada.protocols/Properties about yada HOT 3 CLOSED

If malformed? doesn't require properties to function, then you're right. We want malformed? to be processed as soon as possible, because a bad request should be thrown out as soon as possible, and not involved a database lookup.

I've checked all my resources, and none emit :parameters in the request version (although some emit :parameters in the 'static' non-request version) While I wanted to keep rules about which property can and can't be emitted in either version to a minimum, your case for bringing malformed? forward in the interceptor chain is compelling and I accept your argument - thanks for being so clear.

Perhaps malformed? is also poorly named. Maybe parse-parameters would be better. Of course, if those parameters end up being bad, and uncoerceably so, we send a 400 (Client Error). The name is historic, via Liberator, so it's not essential we keep it. What do you think?

from yada.

Yes I think that would be a good change. The name comes from the spec I guess.

10.4.1 400 Bad Request
The request could not be understood by the server due to malformed syntax.

from yada.

Closed since recent commits

from yada.