Anne, are you suggesting that Blizzard Entertainment Inc., if they port 
World-of-Warcraft to the iPad, should convert to using HTTP and URIs so that 
the 
lag response will be reduced and the users will have a much better experience 
than they have now on desktop/laptop devices?

Can you provide some details of how HTTP provides less lag than UDP does, and 
how TCP resend delays are no longer a problem in real-time multi-media systems 
because HTTP is used on top of TCP?

Gregg Wonderly

Anne Thomas Manes wrote:
>  
> 
> Responding to this specific comment:
> 
>     "HTTP and URI (which isn't REST) "
> 
> 
> Well, actually, HTTP and URI *is* REST. Or at least it's the essence of 
> REST. All interfaces, all interesting bits of information, all 
> interactions, and all application workflow in a RESTful application are 
> driven by HTTP and URIs. As Stefan Tilkov says, REST is using HTTP as it 
> was intended.
> 
> REST is:
> 
>     * Everything of interest has an identifier and the format of those
>       identifiers is uniform (e.g., a URI)
>     * Every identified resource supports a uniform API (e.g., HTTP methods)
>     * The application uses hypermedia to coordinate application state
>       and the process flow (HATEOAS)
> 
> REST is entirely about HTTP and URIs.
> 
> If you intend to support the iPad as a UI device for your service, you 
> should design the service so that client applications can interact with 
> it using HTTP and URIs.
> 
> Anne
> 
> On Wed, Apr 7, 2010 at 2:41 AM, Steve Jones <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>      
> 
>     On 6 April 2010 17:29, Stuart Charlton <[email protected]
>     <mailto:[email protected]>> wrote:
> 
>          Long time no see.   comments inline
> 
> 
>     Internet issues in Oz.
>      
> 
> 
>         Sent from my iPad
> 
>         On 2010-04-05, at 1:44 PM, Steve Jones <[email protected]
>         <mailto:[email protected]>> wrote:
> 
>>          
>>         The other piece that the iPad/iPhone has really demonstrated
>>         is how rarely services are actually re-used between multiple
>>         areas in the "web".  Sure there are a bunch of twitter clients
>>         but most people using Facebook seem to use the standard
>>         Facebook app and most other server/consumer applications are
>>         equally tied to a specific server side implementation that is
>>         used by only one client set.  Whether these elements use REST,
>>         SOAP or anything else is irrelevant as they are tied
>>         applications in a more client/server style mode than a "web"
>>         mode. 
>>
>         The web currently is an extension of a client/server
>         architecture... whether the client is a browser or a dedicated
>         client is somewhat immaterial.
> 
> 
>     Agreed, but this isn't the "vision" that is preached around the web
>     architecture pieces.
>      
> 
> 
> 
>>         For me the iPhone really demonstrates how little there
>>         genuinely is of the "web" application model and how in reality
>>         we are still at a technical client/server model with clients
>>         tied to servers.  IMO part of this is driven by REST and its
>>         lack of proscribed documentation thus making interfaces
>>         obscure to anyone other than those who wrote it.
> 
>         I wont disagree that there is a lack of documentation.... but
>         are you seriously claiming that crappy REST API's are
>         responsible for why there are so many iPhone apps instead of
>         just relying on browser-based apps?      
> 
> 
>     I think its part of it, but not on the iPhone apps v browser based
>     but on the "tied" model of client/server rather than one service
>     multiple clients (twitter aside).
>      
> 
> 
> 
> 
>>         The iPhone/iPad do not demonstrate that REST rules, arguably
>>         they prove quite the opposite, they prove that a client/server
>>         model with proprietary APIs rules and that the "power" of the
>>         web is trumped hugely by a closed garden model.   
> 
>         Last I checked, the best and most widely used application on the
>         iPad was Safari.  The multitouch web experience is easily the
>         biggest draw on these devices.  And that all of the apps, music,
>         or vids you download from iTunes are available via hyperlinks
>         that can be communicated and shared with others.   And that
>         nearly every application grabs its content from servers via HTTP
>         and URI, and can allow you to copy those URIs and use them
>         elsewhere.
> 
> 
>     Not disagreeing but there is a jump from HTTP/URIs and REST as an
>     architectural approach.  I don't disagree that HTTP and URIs are
>     absolutely key here.
>      
> 
> 
>         Yes, there are plenty of proprietary APIs layered on top of
>         those standards.  Time will hopefully help to standardize new
>         media types where they are needed.
> 
>     But don't hold your breath on that one, its been 5+ years that
>     people have been talking about that stuff and what progress has been
>     made?
> 
>      
> 
>           
> 
>         What the iPhone and iPad does is show the Web is not just about
>         browsers. I think you are confusing the politicized process of
>         HTML standards development with architecture.  How can the world
>         suddenly adapt all platforms to a new UI paradigm?  It takes
>         time to standardize deployed practice.  The flood of iApps are
>         an expected occurrence because a piece of the Web, HTML, has to
>         catch up.   Yet both HTTP and URI remain crucial (if incomplete)
>         to the user experience on these devices.   It is completely
>         disingenuous to claim this is all proprietary client/server.  
>         It is, at worst, partially proprietary.  Like most evolving
>         information exchange protocols...   
> 
> 
>     What I'm saying is that while HTTP and URI (which isn't REST) are
>     critical to the user experiences the actual service implementations
>     are effectively proprietary (or partially proprietary if you like)
>     in that a given server side implementation has a fixed client side.
>      There isn't really an new UI paradigm, the iPhone, beyond things
>     like multi-touch, is "just" a rich client platform and people are
>     building client/server applications in the same way they always have
>     by developing them together with the express purpose of them being
>     used as a coherent lump that just happens to be split between a
>     client and server.
> 
>     Its great that we've moved to a common protocol like HTTP and have a
>     common approach like URIs but the "vision" of service assembly
>     hasn't been delivered in reality by REST in anyway shape or form. 
> 
>     So just to be clear
> 
>     HTTP/URIs are a good thing and are used pretty much everywhere
>     99% of iPhone/iPad apps are developed in a client/server mindset in
>     the same way as client/server applications were developed 20 years ago.
> 
>     Steve
>      
> 
> 
>         Stu
> 
>         
> ------------------------------------------------------------------------
>         Looking for the perfect gift?* Give the gift of Flickr!*
>         <http://www.flickr.com/gift/>
> 
> 
> 
> 



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply via email to