I really liked a comment left by an anonymous writer for my "Save REST" post. I think it is worth to mention it again in this post.
I am not sure having a committee and coming up with a standard is a good idea. For example, take W3C standards for HTML. It did not do anything good. We still have to tweak our CSS for web pages to work across multiple browsers. Another example, our dear WS-DEATH * standards.
True. But can we please get an industry accepted de facto technique for securing REST based services?
It seems that most REST services either rely on the non-RESTful cookie/session based approach with a login URL to establish the session, or they implement a custom technique using the Authorization header.
The Authorization header is clearly the right approach, but we need a de facto standard technique for using it. Something along the lines of Amazon's S3 approach would probably be ideal.
I think instead of having a committee for coming up with a standard, we should all start working on different implementation of REST authentication. I think a simple solution will prevail and all the other solutions will fail. Once the simple solution is used by many people , than it will automatically becomes a standard.
Am I dreaming? Let me know what you all think?
5 comments:
Given the commenter mentioned de facto versus de jure, s/he should be implying that it shouldn't be decided by committee but rather by natural selection in the market. However, I'm not sure how much sense it makes to ask for a de facto standard. De facto means "as a matter of fact". If there is no common way of securing REST services as a matter of fact... well then there is no de facto standard. This could be for various reasons. Perhaps, people just don't know what other people are doing and keep re-inventing. Or perhaps people are still trying out different options, none of which are clearly better yet. Or perhaps we just need a dominant player to assert itself.
I agree with what you say. But I'd emphasize that commitees are also part of the gene pool, as Darwin would say.
Commitees have the advantage that they are usually formed by experienced people that know a lot about the topic and they can coordinate knowledge effectively.
Still they will be wrong sometimes as they can't represent the whole world intelligence, in the past, in the present or in the future. So commitees shouldn't be ignored but neither lonely great ideas.
Darwin didn't know about genetics... :)
De facto standards are IMO superior because they are effectively reflecting what the community as a whole has accepted as the way to do things. This doesn't mean that the accepted standard is the best but at least it reflects a much broader spectrum of input than any particular committee.
Standards proposed by committee work best when they either simply acknowledge a pre-existing de facto standard OR the committee is actually filled with facilitative, intelligent, objective, and experienced people (which I'm thinking is actually not that common)
Well yes, "would have said" I should have said ;)
The important thing I think is to allow people to choose and to have options available.
So in this sense I really don't see the opposition between a de facto standard and a comitee standard. Both give options and we are they guys responsible to make them standards. Let them call it standard, we will choose what it's best.
So I think the problem arises because we call "standards" to what commitees propose, instead of calling them "standard proposals".
They are only promoted to standard status if users decide that they should be.
Jason and Daniel thank you for sharing your insights. I will be interested to see how this works out.
Post a Comment