On 7 April 2010 14:00, Anne Thomas Manes <[email protected]> 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. >
Your point there is "as it was intended" HTTP/URI is like giving Petrus to a wino. Sure there is a way that it is "intended" to be used but the wino just knocks it back like meths. HTTP/URI are _tools_. REST is an _approach_. 99% of HTTP/URI implementations are not REST. > > REST is: > > - Everything of interest has an identifier and the format of those > identifiers is uniform (e.g., a URI) > > 99% succeed here.... > > - Every identified resource supports a uniform API (e.g., HTTP methods) > > 10% succeed here.... > > - The application uses hypermedia to coordinate application state and > the process flow (HATEOAS) > > 1% succeed here. > REST is entirely about HTTP and URIs. > That is like saying that the US legal system is entirely about freedom and liberty. > > 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. > Which is *not* the same as doing REST. WS-* can use HTTP and URIs for instance and they certainly aren't REST. Equally you can do POST all over the place and make GET modify state with HTTP and URIs, which again isn't REST. Saying REST = HTTP is like saying WS-* = SOA. Steve > > Anne > > On Wed, Apr 7, 2010 at 2:41 AM, Steve Jones <[email protected]>wrote: > >> >> >> On 6 April 2010 17:29, Stuart Charlton <[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]> 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/> >>> >>> >> > >
