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]> 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/> >> >> > >
