No-magic policy?

[Tahir Hashmi]

Hi,

As you might have seen in the documentation[1], wsloader automagically
enforces POST request method for endpoints (i.e. function or method
names in your application) starting with a fixed set of prefixes. So
far, this is the only bit of magic that wsloader does (along with a
monitoring endpoint, which is undocumented because it's subject to
change). This choice has two huge advantages:

1. The client doesn't have to go through a negotiation step to figure
out whether it should call an end-point on a wsloader hosted service
with the GET method or the POST method

2. It doesn't require the service developer to explicitly specify for
each endpoint whether the request method should be GET or POST.

I consider both of these to be pretty significant advantages. I don't
suppose there's any scope for runtime negotiation of request methods
and having to feed the wsloader client library a configuration for
every service is not a very appealing idea. It smells a bit like the
J2EE deployment descriptors. Even if we provide configurations for
specifying a request method per endpoint, I find value in the platform
protecting the service developer from accidentally missing out on this
detail. More often than accident, it would be mere laziness or
ignorance. We shouldn't penalise laziness and we can't wish away
ignorance.

Do you think that this is a good design choice? Can you suggest
alternatives that solve the problem of non-configuration elegantly?

[1] http://code.google.com/p/wsloader/wiki/Overview#2.4_HTTP_Request_Method_Restriction