UserPreferences

CarrotVsOrange


Carrot vs. Orange

CarrotVsOrange discusses the benefits, drawbacks, and arguments for or against AtomApi approaches "HTTP using GET/POST to a single URI" (Carrot) vs. "HTTP using the REST Architectural Style" (Orange or simply REST).

Poll

Place your name by the option you like best. [OpenPoll]

Note: There is a third option where each resource has its own URI, and GET and POST are directed to the resource URI.

Note: Another option is to have one URI per entry, that accepts GET/POST/PUT/DELETE (REST) and that ALSO accepts a POST with the Content-Type for URL encoded HTML form data. In this way a web browser can use an HTML form to POST commands to the atom service and a REST client can use the direct manipulation REST operations (POST/PUT/DELETE) [BryanThompson].

[HansGerwitz] I want to vote for per-Entry URLs (yes, I meant that L) but with all operations possible via only GET and POST. Does that make me a Squash? [AndrewCates] is anyone aboe to explain WHY carrot is called carrot and orange called orange?

Example code demonstrating this poll is in CarrotVsOrangeExample. See also RestEchoApiDiscuss, CarrotVsOrangeDiscuss.

Initial clarification points

Apache handling of PUT requests

There are at least five ways for Apache to be configured whereby one CGI script can handle requests, regardless of methods directed to a specific range of URIs:

Benefits and Arguments

GET and POST HTTP methods

Benefits
Drawbacks

GET, POST, PUT and DELETE HTTP methods

Benefits
Drawbacks

Server-Side Platform support of PUT and DELETE

See PutDeleteSupport.

Client-Side Platform support of PUT and DELETE

See PutDeleteSupport.

Clients or Servers not able to use POST ''or'' PUT/DELETE for Atom API

See PutDeleteSupport.

Solutions for the Impass between Single API and PUT/DELETE camps

[AsbjornUlsberg] Maybe we should start working on a proxy (-API) that transforms a regular GET/POST request into GET/POST/PUT/DELETE? With such proxies, a PUT-disabled client can post to it with a specified XML format, and the XML is then parsed by the proxy and PUTted to the target server. It should, if we define something like this, be stressed that this API MUST NOT be used for directly POSTs, it should always be routed through a proxy. Hence, we can say that receiving aggregators SHOULD NOT support this API at all.

[RussellBeattie] We need to simply define both specs as "authorized" and establish a simple method for determining which format is used. A simple GET that returns the API type will be sufficient, and the client can cache that from that point on. I say let the developers vote with their code.

[MikeDavies] An intermediate proxy is a good idea with a caveat or two - it leads to the "two APIs problem", and if this proxy API looks like TimBray's original conception, then it would put doubt on the feasibility of a REST framework. If the proxy API is an interim solution "until user-agents support..." then it is the way to go. What we must be sure of is that the number of devices/frameworks requiring the use of this Atom Proxy reduces over time, in favour of full REST support. (And +1 for Russell's "let the developers vote with their code" - if its worth supporting, its worth writing code for it.)

[AsbjornUlsberg] I only want the proxy as a temporary solution until the different frameworks (and developers) supports and understands all HTTP 1.1 verbs. Then, they can be discarded, and the GET/POST/PUT/DELETE can be done directly to the source. Also, I don't want the proxy API to be equivalent to the aggregator API. They are not interchangable, and the proxy API should only be used when the aggregator API can't be supported directly. The proxy API is a fast and temporary soltions for people who don't have the possibility to use the aggregator API directly, and SHOULD be superfluous in a couple of years.


CategoryArchitecture, CategoryApi