*Sigh*
I hope we don't start having a purely philosophical discussion ...
that was not at all my intent.
I believe that
(1) we should focus on HTTP only, not any other theoretically
possible but practically irrelevant REST implementation
(2) we should follow HTTP's explicit and implicit constraints and
architectural decisions as closely as possible
(3) we should make it extremely easy and convenient to build
applications that use HTTP *correctly* - i.e. API users following the
path of least resistance should end up with a Web application that is
"RESTful", possibly without knowing or caring
(4) there should be nothing I can do with HTTP that I can't do with
Java and the JSR 311 API
Also, +1 on Jan's suggestion to incorporate the notion of container
resources, although I have some sympathy if someone questions whether
this is implied strongly enough in the HTTP spec.
Stefan
P.S.: Good to see you here, Jan ;-)
--
Stefan Tilkov, http://www.innoq.com/blog/st/
On Apr 13, 2007, at 4:16 PM, Jan Algermissen wrote:
>
> On Friday, April 13, 2007, at 04:03PM, "Stefan Tilkov"
> <stefan.tilkov_at_innoq.com> wrote:
>
>
> [..] When I
>> use it, I'm referring to the RESTful Web API an application exposes -
>> e.g. I would call the Google Calendar Data API a "REST API". I would
>> say every WADL file describes a Web API, and if it follows REST's
>> constraints (is RESTful), a Web API is a REST API.
>
> I consider HTTP to be a REST API and I am having trouble to see
> what a 'Web API' is (in a REST context). From a strict POV, all you
> get
> to do when you do not want to break REST's constraints is to make
> use of HTTP
> and of (standardized media types). All 'API-like semantics' have to
> be dealt with
> in the MIME type (defined as standardizations of state transition
> semantics, e.g.
> APP's edit-media link rel).
>
> If you have a service that needs exposure of some *DL for the
> client to understand it,
> you break REST.
>
>>
>> So I agree we're not trying to build a REST API. We're trying to
>> produce an API "that makes it easy to build RESTful services",
>
> Maybe I am misunderstanding something, but isn't this
> purely about HTTP? About making it easy to build HTTP-based
> services?
>
> If not, what other REST-architecture besides HTTP do people have
> in mind (IMO it is rather unlikely that we will ever see one :-)[1]
>
> (Maybe) confused,
>
> Jan
>
>
> [1] Besides WAKA, so there might be a point in staying generic.
>
>
> which
>> in my words translates to "that makes it easy to build REST APIs".
>>
>> But I can stop using this term if it causes misunderstandings ;-)
>>
>> Stefan
>> --
>> Stefan Tilkov, http://www.innoq.com/blog/st/
>>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>