+1. REST is about using URIs and HTTP as they were intended. REST is an architectural style. If you don't use URIs and HTTP as they were intended, you aren't doing REST. i.e., It's about applying REST principles in your application design. Just like SOA is an architectural style. If you Don't apply SO principles to the system design, you aren't doing SOA. The difference is that URIs are fundamental to REST, because REST requires hypermedia. You could use another protocol besides HTTP, but no other protocol is as well integrated with URIs and hypermedia as HTTP, so for most situations, REST presumes HTTP.
Please allow me to restate my original point: If you have a service, and you want to enable people to develop iPad/iPhone apps that can easily interact with your service, you should provide a RESTful interface for that service - one that relies on standard Web technologies with no arcane protocols like WS-*. Anne On Wednesday, April 7, 2010, Steve Jones <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 need > > > > > > > > > > > > > > > > > > > > > ------------------------------------ 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/
