PUBLIC MARKS with tag restful

The suggested URI pattern is based on the distinction between non-information resources (abstract or concrete real-world objects), generic resources, and their representations. Generic resources are Web documents describing the abstract object they are associated with (e.g., a Dewey class). The pattern for generic documents defined in the current pool of Dewey URIs is as follows:

Recently InfoQ did a good summary of the debates around the apparent (to some) limitations of REST when it comes to creating good Web services. At issue is that REST APIs seem to expose "CRUDy" services that fly in the face of years of good services design, particularly when they are just read/write interfaces instead of the richer, full REST architecture (more on what this is later.) The discussion was spurred by Arnon Rotem-Gal-Oz's assertion recently that CRUD is bad for REST, which in my opinion is close but not quite right.

J'étais en train de lire RESTful Email over HTTP et ça m'a rappelé un vieux vaporware, je me demande s'il ne serait pas intéressant de regrouper toutes les notifications en un unique endroit. Il suffirait pour cela d'accepter plusieurs choses en entrées :

* emails (pull/push)

* flux (pull)

* jabber (push)

* webhooks (push)

* irc (bonus !)

Django may be the Python web framework getting all the press recently, but web.py is definitely a nice, simple framework. One of the nice aspects of web.py is that it exposes methods for the basic HTTP methods (GET, POST, PUT, DELETE, etc.) and uses these methods to process each request from the client. This approach makes it amazingly easy to write a RESTful API.

API designers, please note the following rules before calling your creation a REST API:

This is a design scratchpad for an HTTP RESTful API for Bugzilla. It will be implemented as a proxy, using a variety of methods (the existing API, web scraping) on the back end and with a clean interface as defined here on the front end.

If this sort of interface were adopted by major email providers, not only would email finally have a nice API, but it would become better integrated with our web ecosystem. For example, email messages would have URLs, and mailboxes would have Atom feeds.