Hi Stefan,
On Friday, April 13, 2007, at 04:50PM, "Stefan Tilkov" <stefan.tilkov_at_innoq.com> wrote:
>*Sigh*
>
>I hope we don't start having a purely philosophical discussion ...
>that was not at all my intent.
Neither mine - though I tend to take a puristic position (as long as
possible :-)
>
>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
Big 'yes' to all of the above.
>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.
Yes, it is definitely debatable (just wanted to illustrate my point).
Another interesting issue is how much REST's application model can/should
influence our API design. Given that the heart of a Web application is a
state machine (portions of which are revealed to the client for the sake
of enabling coordinations between independent processes) should a
developer using our API be dealing with implementing do_GET(),
setHeader() and that sort of thing? While not giving the developers a
comfortable way to specify the state machine and let JSR311 do the
rest (Spring has something like this IIRC).
Sorry if this sounds too sophisticated and I am not honestly proposing the
approach here, but...then....:-)
>Stefan
>
>P.S.: Good to see you here, Jan ;-)
Ebenso!
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
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
>