Items tagged rest in 2008
Filters: Year: 2008 × rest × Sorted by date
The key thing to remember is that REST is about building software that scales to usage on the World Wide Web by being a good participant of the Web ecosystem. Ideally a RESTful API should be designed to be implementable by thousands of websites and consumed by hundreds of applications running on dozens of platforms with zero coupling between the client applications and the Web services.
— Dare Obasanjo # 24th October 2008, 1:39 pm
Magnificent Seven—the value of Atom. The seven core things that Atom solves so that you don’t have to. # 19th October 2008, 10:24 pm
Bloom Filter Resources. A continuation of the discussion about how to transfer information about a large number of recently updated resources around in an efficient way, Joe provides working code illustrating a simple approach using bloom filters. # 19th October 2008, 10:22 pm
Versioning REST Web Services. Peter Williams suggests using a vendor MIME media type in the Accept header to specify a required API version, because embedding the API version in the URL itself leads to a single resource ending up with many different URLs, one for each API version. # 13th October 2008, 12:45 pm
RestView—a class for creating a view that dispatches based on request.method (via) I finally got around to writing up a simple approach I’ve been using for REST-style view functions in Django that dispatch based on request.method. # 21st September 2008, 8:47 pm
Dare left something out (and it’s important). Dave Winer: “You should at least learn the lessons and add to REST what it needs to catch up with XML-RPC. Seriously. What’s missing in REST, btw, is a standard method of serializing structs, lists and scalar types.” That would be JSON. # 18th August 2008, 9:39 am
Explaining REST to Damien Katz. I didn’t know that it was Mark Baker back in 2002 who first pointed out that SOAP was flawed because it ignored the architecture of the Web as defined by Roy Fielding’s Ph.D thesis. # 17th August 2008, 11:19 pm
REST, I just don’t get it. Read the comments for some excellent practical reasons to care about REST, including cache management (PUT and DELETE can expire the cache entries for the corresponding GET), the ability to add or move parts of the server API without redeploying client libraries and the idempotency of GET / PUT / DELETE and HEAD (repeated POST operations may have side-effects). # 15th August 2008, 8:20 am
If it’s easy to make all your calls conform to the RESTful verb architecture, then that’s good, I guess. But if not, then just use a POST as an RPC call, keep it as simple as possible and be done with it. And don’t spend another minute worrying about being RESTful or not.
— Damien Katz # 15th August 2008, 8:07 am
What is it like to write a technical book? Plenty of food for thought from the lead author of the new edition of High Performance MySQL. It’s amazing how Word is still an integral part of most technical book projects despite its obvious inadequacies compared to a toolchain based on plain text files and Subversion (the Django Book used ReST and Subversion to great effect). # 20th June 2008, 8:18 am
Persevere adds Comet Support. Persevere sounds neat: a RESTful HTTP/JSON data store (the interface reminds me of CouchDB) which recently gained the ability to “subscribe” to a resource and receive notifications of updates via comet. # 13th May 2008, 8:09 am
Multi-Inflection-Point Alert. Dammit, Tim, stop giving away our competitive advantages! # 26th April 2008, 6:48 pm
I’ve never heard anyone from the REST camp claim that building distributed systems was “easy”. [...] The WS-* folks have historically been obsessed with making things easy, usually for an imaginary business analyst who is nowhere near as technically adept as they. The REST folks, on the other hand, seem much more interested in keeping the entire stack simple, and for everyone involved.
— Ryan Tomayko # 13th January 2008, 11:34 pm