https://bugzilla.wikimedia.org/show_bug.cgi?id=41837
--- Comment #17 from Daniel Friesen <[email protected]> 2012-11-07 08:41:48 UTC --- I did some actual severe reading on "REST". Unfortunately it seems that "REST" is now used to refer to two completely different things. The original REST. This REST is the original that Roy Fielding defined in his doctoral dissertation. The goal of this REST is NOT what you see in all these per-site/per-software proprietary APIs. But is actually intended for long term things that work at the scale of the entire internet. Unfortunately even after reading and understanding it I'm not quite sure I could even explain it that well. Anyways, no one who says they use REST is actually using rest. Better -- but perhaps not perfect -- examples of REST clients, would be web browsers and Atom feed readers. The second REST. This REST is the rest practically everyone is really talking about when they say they use rest. While in a way based on the real original rest. This REST is really so twisted, distorted, and defiled that the only similarities between it and the original rest amount to using HTTP properly when you use it (ie: practice things that are good for caching, and never use GET for things that trigger an action). The rest of this REST are not just different from the original, many of them actively violate the core principles of actual REST. And don't bother with our Wikipedia article. It basically tries to fuse both types of REST into one page as if they were one and the same. The result being a page that at best contradicts itself. And it's not something all that easy to fix. ---- Now the original REST is for internet scale things. The goal is different than what the goal of our API is. While implementing this type of REST would be a very admirable goal, it would have basically nothing to do with our API. And it would be a different kind of project. As for the buzzword type REST. This type of REST has limited use. There aren't really any advantages to it. Many of the supposed advantages of this type of rest such as cacheability and statelessness are really just advantages of using HTTP intelligently and have nothing to to with the specific REST patterns and restrictions. ie: This type of REST is about as worthless as MVC frameworks are to the good practice of MVC. And now. I should probably point out something. Switching from our query parameters to /pageinfo/... is not REST. The real original REST does not mandate url formats. And using a root like /pageinfo/ also violates the url patterns used in the mangled REST. ---- So the general closing point. Put some actual critical thought into each idea you have for the api and decide whether it's a good idea based on the pros and cons specific to it. Instead of clinging to the idea because some desecrated buzzword says you should do it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
