Talk:Representational state transfer

From Wikipedia, the free encyclopedia
Jump to: navigation, search


WikiProject Internet  
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 
WikiProject Spoken Wikipedia
WikiProject icon This article is within the scope of WikiProject Spoken Wikipedia, a collaborative effort to improve the coverage of articles that are spoken on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 

More concrete information on RESTFul web services[edit]

I believe that people will come to this article seeking a concrete understanding of RESTFul web services. There is a lot of practical and concrete material in Leonard Richardson and Sam Ruby's Book which I added to the references in the article.

I would like to include the section that I have drafted here: http://en.wikipedia.org/wiki/User:Nicholsr/REST#RESTful_Web_services into this article. I think this would help readers understand REST in practice a little better. Nicholsr (talk) 09:03, 1 December 2008 (UTC)

I see this has now been implemented in the article in an altered form. In particular PUT and POST seem to be the wrong way round. I'm going to fix that now as I'm pretty sure that it is wrong unless I'm going mad. Oligomous (talk) 17:51, 12 May 2010 (UTC)
Oligomous - You must be going mad. ;) I'm pretty sure the POST and PUT definitions were correct, and you swapped them. I don't have my copy of RESTful Web Services handy to verify, but this answer on stack overflow verifies. Keithjgrant (talk) 22:50, 13 May 2010 (UTC)

Addition: I found the following articles helpful from a practitioner's point of view:

86.135.85.98 (talk) 11:50, 16 October 2010 (UTC)

Fielding frustrated about what APIs are called REST APIs[edit]

See REST APIs must be hypertext-driven.

--Marc van Woerkom (talk) 13:52, 8 December 2008 (UTC)

Obviously (see comment #8) he seems not too happy about the Wikipedia article as well:
To some extent, people get REST wrong because I failed to include enough detail on media type design within my dissertation. That’s because I ran out of time, not because I thought it was any less important than the other aspects of REST. Likewise, I suspect a lot of people get it wrong because they read only the Wikipedia entry on the subject, which is not based on authoritative sources.
--Marc van Woerkom (talk) 14:03, 8 December 2008 (UTC)
Fielding is quite at liberty to correct the Wikipedia article, if he is concerned that it is not authoritative enough. - Paul (talk) 12:30, 4 May 2009 (UTC)

He has already supplied the authoritative document on REST - it's our responsibility to reference and cite it properly, which we have so far failed to do.

Article cleanup[edit]

Some suggestions for the editors:

1) Decide on an unambiguous definition of REST. IMHO, Fielding lost and the engineers won. REST = XML over HTTP, and it has a particularly important role as a vastly simpler alternative to SOAP.

I'd say this is a good reference: http://www.xfront.com/REST-Web-Services.html

2) Clean up all of the hype. For sheer vapor, REST is right up there with Ruby on Rails.

This article has been in sad shape for WAY too long. It needs some serious attention. 66.117.135.137 (talk) 10:08, 31 December 2008 (UTC)

Fielding *defined* REST in his thesis. While the term has been misappropriated to talk about XML over HTTP, that's no justification for making the REST article about it. I'd be supportive of making that distinction clear very early in the article, but not removing the distinction altogether.
What hype are you referring to that should be removed? Honest question.
I'd agree this article could use some significant cleanup. :/
jsled (talk) 17:20, 31 December 2008 (UTC)
There are plenty of examples of RESTful services which do not use XML. JSON and and YAML are other very common data types in use Nicholsr (talk) 00:28, 16 January 2009 (UTC)
It should not be Wikipedia's role to judge what should be called REST, who is right or who should own the term. If there are two widespread different but conflicting ideas about REST is, or two different practices calling themselves REST (i.e., Fielding's definition vs. the XML over HTTP camp) then this article should describe those two camps / definitions, their origins and differences.--Ericjs (talk) 20:59, 12 February 2010 (UTC)

CRUD mapping: (PUT,POST) ≟ (CREATE,UPDATE) or ≟ (UPDATE,CREATE)[edit]

People keep swapping PUT/POST in relation to the CRUD semantics. The most appropriate mapping is POST=CREATE, PUT=UPDATE…

From RFC 2616, re:POST:

POST is designed to allow a uniform method to cover the following functions:
  • Annotation of existing resources;
  • Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
[…]
  • Extending a database through an append operation."[1]

Note that "annotation" is not necessarily updating existing resources, but creation annotations of those resource.

From RFC 2616 for PUT:

"In contrast [with POST], the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource."[2]

Though there's not a 100% equivalent mapping, and while PUT can explicitly be used to CREATE a resource, the most appropriate mapping is POST=create subordinate resource and PUT=update existing resource. 216.114.130.196 (talk) 16:52, 7 January 2009 (UTC)

I don't understand how you can say that. You point out the first flaw yourself in saying that PUT can create, but a bigger one is in the idea that POST has something to do with creation of resources. There is absolutely nothing to suggest that this is what any POST will do. It can do creation operations (or indeed, updates, deletions or act as an inefficient GET) or it can do something that doesn't fit into the CRUD mapping at all. In CRUD you CREATE at a particular place, if you want to do that in HTTP you use PUT.
The only time POST is most appropriate for creation is when the handler will decide what and where something gets created. This does not map to CRUD. It does map better to CRUDE with POST being the EXECUTE of CRUDE. To the extent that the analogy is useful, I'd put it there, though I don't think the analogy is so useful as to make dwelling on it profitable.
Why do you remove the item from the text you quoted which doesn't fit your argument, rather than just see it as already refuting it? Why do you say 'Note that "annotation" is not necessarily updating existing resources, but creation annotations of those resource.' when there is nothing to indicate whether it is an update or a creation - it could well be either or something else besides. Talliesin (talk) 09:34, 18 September 2009 (UTC)
I was 216.114.130.196 at the time. I suppose I was going for a rough, "best-fit" mapping of the HTTP methods to "CRUD", without footnotes, parentheticals, qualifications or changing the acronym. I acknowledge that PUT can be used for creating, and POST covers other functions; there is the long-standing POST(p[rocess]) and POST(a[ppend]) distinction. But if we're just trying to allocate the core HTTP methods to CRUD initials one-to-one, I think the most appropriate mapping is POST=CREATE (similar to INSERT with an auto-increment primary-key column) and PUT=UPDATE.
Maybe the best thing for the text is to say there is no clear mapping, since both POST and PUT are defined in terms of both creating and updating resources (and doing even more, potentially, in the case of POST). jsled (talk) 14:37, 18 September 2009 (UTC)
User 170.171.10.30 recently removed all references to HTTP, including the little table we used to have mapping HTTP verbs to CRUD actions. I admit I wasn't too chuffed at the time (see #Too much removal?? below) but actually we snuck a few bits back in, wrote some new stuff, tweaked here and there, and I think the article really is better after the purge. One of the bits someone snuck back in (not me) is the table at Representational State Transfer#RESTful web services, which I think is worth a read. The way I understand it is this: POST to a collection URI creates a record in that collection; PUT to a non-existent item URI creates that item; PUT to a current item URI updates that item. Other combinations are possible, but their usefulness is generally less clear. As far as the article is concerned, I think these points are well covered in that table, and as we're trying to minimise the binding between the bulk of the article and HTTP, I think that's enough. In other words, I don't think we need any new coverage of the points you've been debating here. Having looked at the table, do you agree? --Nigelj (talk) 16:08, 18 September 2009 (UTC)

Idempotency[edit]

Something that should probably be added: I'm not sure where to find a good reference for this, but all RESTful methods except POST are supposed to be idempotent. That is, it should be harmless to do an additional GET, PUT, or DELETE in the event of not getting a response.

With careful design, one can render even the non-idempotency of POST irrelevant. Basically, you design your service so that the client can do a series of PUTs to some sort of holding zone; then the can POST simply be a command to act on the data that has already been passed by PUTs. - Jmabel | Talk 19:20, 2 April 2009 (UTC)

URI/URL[edit]

In this context, shouldn't we refer consistently to URI rather than URL? - Jmabel | Talk 19:21, 2 April 2009 (UTC)

Yes, URL is an obsoleted term. Fielding agrees. 170.171.10.30 (talk) 16:31, 30 July 2009 (UTC)

HTTP 200 or 404 on bad requests[edit]

Say what a request that asks for e.g., planet=Msrs should give back, HTTP 200 or 404? Jidanni (talk) 04:21, 12 May 2009 (UTC)

This has nothing to do with REST. Just HTTP. —Preceding unsigned comment added by 170.171.10.30 (talk) 22:03, 11 August 2009 (UTC)

Though assuming there's no such resource, the 404, obviously. (410 if it's known that there used to be such a resource, it was removed, and there are no plans to put it back; e.g. planet=Pluto) Talliesin (talk) 09:36, 18 September 2009 (UTC)

Requested move[edit]

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was no consensus to move the page from Representational State Transfer to REST, per the discussion below. Also note that the proposed title does not currently redirect to this page; other things are also referred to as "REST". Dekimasuよ! 10:18, 31 May 2009 (UTC)


As per WP:NC, "Titles should be brief without being ambiguous". This technology is almost always referred to as "REST" and almost never as "Representational State Transfer". This move would lead to a shorter, more manageable title and less confusion for readers. — Hm2k (talk) 09:31, 26 May 2009 (UTC)

Survey[edit]

Feel free to state your position on the renaming proposal by beginning a new line in this section with *'''Support''' or *'''Oppose''', then sign your comment with ~~~~. Since polling is not a substitute for discussion, please explain your reasons, taking into account Wikipedia's naming conventions.
  • Mild Oppose: I remember making a similar suggestion in the past for Enhanced Data Rates for GSM EvolutionEDGE; my arguement there was that the backronym meaning of the letters EDGE had changed over time (the latters hadn't). For REST, I don't see a gain from renaming it to "REST" alone, but do think that it should possibly be renamed to be the lowercase "Representational state transfer" to match the introduction, as there is no word to provide the 'E'. —Sladen (talk) 16:27, 26 May 2009 (UTC)
  • Oppose: It's always referenced as both "REST" and "Representational State Transfer" as I've encountered it … often with the expansion of the name used to emphasise a point about focusing on Representations. I don't think "REST" has quite the status that "laser" or "radar" do. Additionally, technology is a acronym-heavy field, but that doesn't mean the "proper" identifier is the acronym. Looking at the Template:IPstack, for instance, has very few acronyms as names. Clearly, "http://wikipedia.org/REST" should get the user here to this article very quickly, but it doesn't need to be the name. jsled (talk) 03:50, 27 May 2009 (UTC)
  • Comment the dab page presents several values for REST... 70.29.208.129 (talk) 03:10, 28 May 2009 (UTC)
The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Removed material[edit]

Partially in response to some comments above (e.g. #REST is an architectural style for distributed hypermedia systems and #I do not get it) and partially simply because they were some combination of being rambling, confusing, overly abstract, confused or incomprehensible as well as being uncited and unreferenced, I have removed the following text blocks from the article:

In the strictest sense, REST refers to a collection of network architecture principles that outline how resources are defined and addressed. Usually, however, the term is more loosely used to describe any simple interface that transmits domain-specific data over HTTP, without an additional messaging layer such as SOAP or session tracking via HTTP cookies. These two meanings can conflict and overlap.


- If we start off by saying it has two meanings, then that makes the whole thing confusing. I suggest a separate article for the other meaning (If it legitimately exisis, which I doubt. I think the two usages are by 'those who understand it' and by 'those who don't')

The difference between the uses of the term "REST" therefore causes some confusion in technical discussions.


- See above

Claimed benefits

Many of the statements below refer to REST in the specific context of Web Services, as opposed to SOAP. REST was originally defined in Fielding's dissertation in the context of information and media access. Fielding did not originally contrast REST with RPC.

Some benefits with REST:

  • Provides improved response time and reduced server load due to its support for the caching of representations
  • Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
  • Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
  • Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
  • Provides equivalent functionality when compared to alternative approaches to communication
  • Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
  • Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
    • The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
    • The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.

One benefit that's obvious with regards to web based applications is that a RESTful implementation allows a user to bookmark specific "queries" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this "representation" of a path or entry point into an application state becomes highly portable.


- Not clear as to being benefits when compared with what, for what purpose. Someone has tried to clarify in italics above, but this is too soon in the article. Who's trying to 'sell' us something here? There's nothing to buy, it's a design principle. Totally uncited. Every point could be counter-argued. No purpose.

Some "RESTful" services will extend the POST method to include the operations of updating and deleting by including additional arguments (e.g. method=delete,method=update). However, in doing so the service is moving the "operation" out of HTTP and inside the request data (similar to a RPC style or SOAP web service).


- Well, if they do, then they're not really REST, are they? We're back to the two meanings again - one for those who get it and one to include all those who don't. So they can say they're RESTful too, cos it's a cool buzzword?

HTTP separates the notions of a web server and a web browser. This allows the implementation of each to vary from the other based on the client-server principle. When used RESTfully, HTTP is stateless. Each message contains all the information necessary to understand the request when combined with state at the resource. As a result, neither the client nor the server needs to remember any communication state between messages. Any state retained by the server must be modeled as a resource.


- I have never read a longer definition of stateless. And it's all pointless because the state of the client is altered by a GET, and PUT, POST etc all alter the server's state. It's the network that's stateless. HTTP, which this refers to, is hyperlinked anyway. And who says how the server MUST model its state? (uncited)

HTTP provides mechanisms to control caching, and permits a conversation between web browser and web cache to occur using the same mechanisms as between web browser and web server. No layer can access any conversation other than the one it is immediately involved with.


- Again, getting started for the most detailed definition of caching, but there's no need because that's HTTP and the internet, not REST, and so discussed elsewhere and makes no difference here.

For this reason some "RESTful" services will overload the POST method to make it perform the operation updating (PUT) and deleting (DELETE) a resource.


- again, so they're not really RESTful, are they?

The statements below refer to REST in the context of Web Services, specifically as opposed to SOAP. Note that Fielding's dissertation presents REST in the context of information and media access, not web services. It does not contrast REST to RPC, although it does contrast RPC to HTTP (which is used to illustrate an implementation of REST).

REST
Resources—Commands are defined in simple terms: resources to be retrieved, stored / get, set—difficult to do many joins
RPC
Commands—Commands are defined in methods with varying complexity: depending on "standard"—easier to hide complex things behind a method
REST
Nouns—Exchanging resources and concepts
RPC
Verbs—Exchanging methods
REST Triangle of nouns, verbs, and content types.

A RESTful web application requires a different design approach from an RPC application.

An RPC application is exposed as one or more network objects, each with an often unique set of functions which can be invoked. Before a client communicates with the application it must have knowledge of the object identity in order to locate it and must also have knowledge of the object type in order to communicate with it.

RESTful design constrains the aspects of a resource which define its interface (the verbs and content types). This leads to the definition of fewer types on the network than an RPC-based application but more resource identifiers (nouns). REST design seeks to define a set of resources with which clients can interact uniformly, and to provide hyperlinks between resources which clients can navigate without requiring knowledge of the whole resource set. Server-provided forms can also be used in a RESTful environment to describe how clients should construct a URL in order to navigate to a particular resource.


- This is almost incomprehensible. The only useful bit was 'A RESTful web application requires a different design approach from an RPC application', so I put that back. What do the brackets mean in that diagram? Where's the discussion of MIME as an equal partner? Any references for any of this???

Uniform interfaces in REST and RPC

The uniform interface allows clients to access data from a range of resources without special code to deal with each one, so long as it is actually uniform. The content returned from a user resource could be the globally standard and RESTful HTML, a less RESTful industry standard representation such as UserML, or an unRESTful application-specific data format. Which content is returned can be negotiated at request time. The content could even be a combination of these representations: HTML can be marked up with microformats which have general or industry-specific appeal, and these microformats can be extended with application-specific information.

Uniform interfaces reduce the cost of client software by ensuring it is only written once, rather than once per application it has to deal with. Both REST and RPC designs may try to maximise the uniformity of the interface they expose by conforming to industry or global standards. In the RPC model these standards are primarily in the form of standard type definitions and standard choreography. In REST it is primarily the choice of standard content types and verbs which controls uniformity.


- Another baffling subsection. It's very prescriptive - apparently now even the returned format can make it non-REST and only HTML is really acceptable. Whatever happened to XML and JSON discussed positively earlier (and of course OK)? And does this author really expect to only ever write one REST client and use it over and over for the rest of his life? Not real. Not cited. Made up.

Other interfaces that use HTTP to tunnel function calls or which offer a "POX/HTTP" (Plain Old XML over HTTP) endpoint are also sometimes referred to as "REST" interfaces.<<Fact!date-April 2008>>


- back to confusing the issue again, saying we're all RESTful now, just different kinds of REST!


Various weasel phrases such as "Proponents of REST argue that ..." have also been culled.

The 'Example' subsection was simplified. There was no reason to duplicate all the example code for 'location' if it wasn't referred to in the explanation

I left the following in, in the hope that someone really is going to come back and expand it:

Many of these uniform interfaces follow document-oriented REST patterns rather than object-oriented patterns [should expand on and thus clarify this distinction]:


I left all the non-web stuff alone too. My specialism is the web, so I'm not really the one to comment on that.

I took the 'Confusing' tag off, in the hope that this was the bulk of the stuff that was throwing people off as they read the article. I hope that we can now hone what's left into something more readable and that better covers the real territory, without wandering aimlessly off down so may blind alleys.

--Nigelj (talk) 16:58, 20 June 2009 (UTC)


Misleading[edit]

The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML, XML or JSON document of some kind, although it may be an image, plain text, or any other content.


Just understanding HTML or JSON etc. is not enough - the API needs to specify how to interpret the fields and content that is part of the hypertext, so that the client can navigate resources via hypertext. —Preceding unsigned comment added by 170.171.10.30 (talk) 16:53, 30 July 2009 (UTC)

Too much removal??[edit]

I removed a lot of, what I considered to be, misleading and confusing stuff from this article recently, and detailed the removals carefully above. While I've been away, it seems that user 170.171.10.30 has removed a great deal more, with very little comment, apart from the many edit summaries. And then user FuzzyBSc has added his/her own brand new essay to pad it back out (with the only references being to "Roy said x" primary-source bulletin boards).

I think we may have gone too far. The article is now very heavy reading, it now reads more like a PhD thesis itself, I fear. Much of the removal seems to have been on the basis that "This is about HTTP, REST is not HTTP" and so it goes. But the replacement essay seems to be all about HTTP, but without mentioning it, or any examples. It is also without any discussion or viewpoints other than those of our friend Roy, unmitigated by any recognisable reference to reality.

The simplest way to put my worries is to say that it is fundamental to WP:RS that we should not depend on primary sources (e.g. Fielding's PhD thesis and his personal comments on it from internet chat) but on secondary sources like what other academics and practitioners, text-book writers and respected commentators have made of what he said. I think we were closer to that with this article at some point in the recent past, i.e. about here, although I agree that the 'Outside the Web' stuff should go, and the examples may be better labelled as such and as no more than examples.

What do other users think? --Nigelj (talk) 22:21, 11 August 2009 (UTC)

I'd started to revert one of those "HTTP is not REST" edits, before wavering and canceling the revert. While I can appreciate the sentiment, it's important to acknowledge HTTP as being highly interrelated with the development of REST, as well as being the most well known/biggest concrete implementation of REST. I guess I ultimately canceled my revert because I used 'pedagogy' while describing my reasoning, and realize that [[Wikipedia::NOTTEXTBOOK]]. At the same time, a little concreteness via HTTP could go a long way to making the page comprehensible to readers.
I'd agree the User:FuzzyBSc additions have some problems, primarily the whole "rest state" nonsense. At the same time, in there lies a pretty good procedural description of the concept of REST. jsled (talk) 23:17, 11 August 2009 (UTC)
(Whooops! Sorry about the formatting. "It's All Text" and wikipedia-mode seem to have conspired against me, there. :) jsled (talk) 15:10, 12 August 2009 (UTC)

HTTP is the primary protocol used in REST implementations, but HTTP itself is not inherently REST. The REST specification does not mention HTTP anywhere, but I agree it's worth discussing in this article. But too much of the previous content focused on misleading or irrelevant things like how to assemble URIs, which is a detail of HTTP - the only thing REST requires of URIs is that they are opaque (not as suggested in removed content, which seemed to imply that hierarchically structured URIs are part of REST). Proper usage of HTTP verbs like GET and POST are necessary for REST when using HTTP, but the removed content suggested that these verbs must map to CRUD-like actions, which is totally inaccurate and misleading.

If you want to see a great example of a properly RESTful HTTP-based service, look at Sun's cloud API: http://kenai.com/projects/suncloudapis/pages/Home It is largely a description of its various media types, which a REST API should be. It's the best example I've seen of REST, with excellent documentation. Maybe this could help to understand how to give some implementation example in this article. CRUD operations based on hard-coded URIs is definitely not what REST is about.

As REST is now a trendy buzzword, we should be careful how we write this article. People love to label their services REST based on a thousand different misguided interpretations ("REST means simple and clean", "REST means CRUD", "REST means pretty URIs" etc) when REST is actually an architecture with very specific constraints.

Also regarding WP:RS: Fielding is appropriate to cite here, and I agree with the need for more third party sources, but I think that most of the removed content did not rely on reliable sources (though lacking citations), but rather unreliable ideas of what REST is based on Wikipedia editors' own interpretations, which is against WP:RS. I'd love to see reliable source citations for some of the removed content, as I'm willing to guess they don't exist outside of misguided blog posts and so on. There's an absolute wealth of misinterpretations of REST out there online, so let's not let that overwhelm the information minority from reliable sources. 170.171.10.30 (talk) 16:37, 13 August 2009 (UTC)

Missing Vinoski reference[edit]

Some material citing Steve Vinoski was recently commented out, due to lack of references. While I don't know if we want to keep all of the content, I googled the first quote ("Imagine, for example, that the web...") and found this:

Steve Vinoski, "REST Eye for the SOA Guy," IEEE Internet Computing, vol. 11, no. 1, pp. 82-84, Jan./Feb. 2007, doi:10.1109/MIC.2007.22
on http://www2.computer.org/portal/web/csdl/doi/10.1109/MIC.2007.22

and for the second quote ("The more specific the service interface..."), I found this:

Steve Vinoski, "Serendipitous Reuse," IEEE Internet Computing, vol. 12, no. 1, pp. 84-87, Jan./Feb. 2008, doi:10.1109/MIC.2008.20
on http://www2.computer.org/portal/web/csdl/doi/10.1109/MIC.2008.20

I also wonder if Steve Vinoski's Blog was written by the same Steve Vinoski. Looks like the same one, for whatever that's worth. In any event, I did the googling, so someone else gets to do the editing. Cheers. ...but what do you think? ~B Fizz (talk) 19:09, 12 September 2009 (UTC)

note the wikipedia article was citing him as "Vinonski" instead of "Vinoski"...apparently a typo? ...but what do you think? ~B Fizz (talk) 19:15, 12 September 2009 (UTC)

CICS[edit]

Would the CICS transactional style of client-server program interaction qualify as a REST protocol? — Loadmaster (talk) 01:05, 8 October 2009 (UTC)

I dearly hope that your question was a mistake and that you realize REST is most definitely not a protocol, but an architecture. There's a huge gaping difference there. —Preceding unsigned comment added by 24.62.204.142 (talk) 12:38, 14 December 2009 (UTC)
Okay, I'll rephrase the question: Does the client/server architecture of CICS qualify as a REST architecture? It seems to meet the important points in the Constraints section. — Loadmaster (talk) 21:48, 7 January 2010 (UTC)
I second the question: my recollection of 3270 terminal-based systems from the 80's (and still in use at places like Costco and IKEA) definitely feels like web clients over HTTP today. Toybuilder (talk) 06:19, 26 April 2010 (UTC)

Problems with References[edit]

  • History section refers to "Zhang, 2004" although this publication is not listed in the article --AlastairIrvine (talk) 07:25, 20 October 2009 (UTC)

Modifications and extensions of REST stlye[edit]

I've added a new short section pointing to new styles derived from REST, currently the CREST and ARRESTED styles. Comments? —Preceding unsigned comment added by Izuzak (talkcontribs) 19:42, 27 December 2009 (UTC)

Statelessness[edit]

The section on statelessness is partially incorrect. Session-based cookies meet the criteria as currently defined, but they are not considered stateless or RESTful. Alternately, if you take the definition very strictly to exclude cookie sessions, then no serious applications can be RESTful. The statelessness criterion is actually that all context associated with a request is either embedded in the request payload or if not carried in the payload they are named by URLs. Cookie session values are not nameable by URI, and all the session values are not included in each request, thus they are not stateless. --Naasking (talk) 20:29, 29 April 2010 (UTC)

Our article says, "no client context being stored on the server between requests". Fielding's dissertation[1] says, "the client-stateless-server (CSS) style ... cannot take advantage of any stored context on the server". I don't see a problem. Cookie data is stored on the client, and is sent to the server with every request during the session (or the lifetime of the cookie). Nothing is stored on the server related to the state of every client. Are you muddling "Session-based cookies" and "cookie sessions" in some way that is defined by whatever proprietary web development environment it is that you are used to? Regarding URLs, almost anything that can be stored in a cookie (and sent with the headers of every request) could be appended to the URL of these requests (or added to the POST data when that verb is used). The resulting URLs would be horrible, but it could be done. It is true that if you store whole database objects in your client's server-side JSP or ASP.NET 'session' variable, or use those environments' built-in session-based logon and credential management stuff, then you have not built a RESTful system. --Nigelj (talk) 21:00, 29 April 2010 (UTC)

By "session-based cookies" I meant an ASP.NET-style session pattern, yes. Any use of such a session is not RESTful, nor is the use of any similar context that is not addressed by URL or provided inline. My point is, the description used by Fielding and in the wiki page is too easy to misinterpret. "cannot take advantage of any stored context" implies there cannot be server-side state. Of course this isn't true, because a lack of server-side state is impossible for any meaningful application, and so everyone misinterprets this phrasing in their own way leading to much confusion. What was meant is that all such server-side state must be addressable by URL. I think this sort of phrasing would clarify the intent, and further clarifies how REST is a composition of simple messaging and addressing primitives. --Naasking (talk) 03:43, 30 April 2010 (UTC)

It is true that you can't build a RESTful system if you make free use of use all the Microsoft stuff that comes with ASP.NET. That does not mean that you can't build "any meaningful application" RESTfully - just look at what the Ruby guys are doing, for example. REST is Representational State Transfer, and so sometimes state is transferred (by e.g. POST, PUT, DELETE) to the server and the server's state is changed. So it is possible to have a database and to have clients alter it. What breaks the REST architecture, for example, is if you have an HttpContext.Session object on the server for each logged-on user and in it you save all kinds of details about the specific user's state - authenticated, admin-user, 12 days until his password expires, will be logged off in 14 minutes if he doesn't do something before then, likely to request this, that, and the other database records again soon, so we have them cached in session for him, etc, etc. That is a practical meaning of the words "no client context being stored on the server between requests" in the article. If you do all those things for each client, your application will not scale beyond a certain number of concurrent users - that's bad design, but it's built into ASP.NET unless you go to lengths to prevent it being used. It's OK for an intranet app, but then that's ASP.NET for you, IMHO. --Nigelj (talk) 23:04, 30 April 2010 (UTC)

You're not really addressing my point regarding the wording on the wiki page. All that context you list would conform to the REST model if it were addressable by URL and thus conformed to URL semantics/lifecycle/etc., or if it were passed explicitly in each request. This is not clear given the current wording in "statelessness". --Naasking (talk) 16:10, 3 May 2010 (UTC)

Just a load of buzzwords.[edit]

This article needs a rewrite. Seriously, every other word is a buzzword. Wikipedia is for information and encyclopedic content, not articles chock-full of information that entrepreneurs and poseurs pass around. 90.196.224.179 (talk) 15:47, 17 May 2010 (UTC)

obvious troll is obvious. please try making a point next time, douchebag —Preceding unsigned comment added by 213.133.206.240 (talk) 18:31, 17 May 2010 (UTC)
Please point out which items are buzzwords? Much of the content is a summarization of Fielding's dissertation, not the most buzz-wordy type of document. jsled (talk) 18:28, 17 May 2010 (UTC)
Has it come to anyone that Fielding's dissertation may be pointless and be full of buzzwords as well? :) Not for trolling sake, but clarity of the term. Article is about nothing. It does not define the term, does not explain mechanics of Representational State Transfer and to my opinion represents sad state of academic science. 216.38.138.34 (talk) 00:11, 7 October 2010 (UTC)
That may be the case ['Fielding's dissertation may be pointless and be full of buzzwords'], but we would need serious academic sources that say so before we could act on it in the article. Do you have any refs that point us to more academic descriptions of REST, or denounce it as nonsense for good reasons, or explain it sans the buzzwords (and without commercial hype)? I'd be glad to help incorporate their findings into the article. Please list them here. --Nigelj (talk) 11:13, 7 October 2010 (UTC)

In my case I agree: I have little chance to understand what REST and RESTful means from this article. The About section is simply misleading. We should start with: what means REST and RESTful? The about sections is a list of buzzwords. — Preceding unsigned comment added by 77.56.162.37 (talk) 18:30, 25 May 2012 (UTC)

Sorry, but even the first line is: REST is a style! I personally have no clue what this means. I agree that this article should be rewritten. — Preceding unsigned comment added by 77.56.162.37 (talk) 18:40, 25 May 2012 (UTC)

Totally agree. The article needs some concrete examples at the top. The only concrete example in it is mapping service actions (list all articles, create article, delete article, etc.) to HTTP actions on nicely readable URLs. I.e. instead of "GET http://example.com/delete_article?article_id=23" you do "DELETE http://example.com/articles/23". If that's all it is, well a) that's really stupid, b) do we need a whole taxonomy for that? and c) it should say it at the top of the article so people don't waste their time thinking there is more to it! 86.132.24.70 (talk) 22:18, 23 July 2012 (UTC)

Still agree. The original comment was two years ago. The article is still incredibly difficult to understand. I have two to three years of university-level computer science education and have worked in the field (though not Web sites) for a decade. 86.182.223.14 (talk) 00:03, 26 July 2012 (UTC)
I think the article was quite different when the original comment was made in 2010, so it might be better to make a new thread at the bottom to discuss this. That said, I don't know who wrote the 'About' section, and I agree that it is almost impenetrable tosh. It's almost entirely un-referenced (the two references that are there are to comments made on a Google Groups bulletin board in 2006). I would prefer simply to delete it and the following 'Key goals' section (also unreferenced, except for a too-long quote from the Fielding dissertation). That would mean that we would quickly get straight into the technical description and definitions of the architectural style. The trouble is that I know that there are non-technical people reading Wikipedia to find out what some of these terms mean - managers, employers, customers and such included. There are a lot of shysters at large on the modern WWW, who don't know much about what they do, but certainly want to talk big and charge a lot of money for the things they can do. These are the ones who can talk endless drivel about REST, Web 2.0, HTML5 etc etc, without ever mentioning that they are conceptually very simple and actually not much of a big deal in themselves. We need to say this, up front, for the non-techies before going into the software/protocol/architectural details below. The problem is references - we should not attempt to write this introduction 'off the top of our heads'. We need third-party, secondary sources that discuss the real REST dispassionately and straightforwardly, from a software systems, and from a users', and from the funder's, owner's and maintainer's points of view. With all the years that have gone by, such things must exist in university-level textbooks by now surely? I'm no longer at university, nor active in the software industry, so I'm not likely to stumble across such a book without some effort, and I have no lecturers (professors) to recommend the best either. --Nigelj (talk) 13:42, 26 July 2012 (UTC)

Have to side with the original commenter. This article is a load of dingos kidneys. It defines precisely nothing yet manages to take up several pages below the fold. Personally, I think this (along with mvc and all the other rubbish) is just the dying embers of Web BS 2.* but thats my 2c. Perhaps if you could show any stark DIFFERENCE between what its being suggested here and actual programming practice - and why its GOOD perhaps?? - this article might be taken seriously. But I strongly doubt that such a distinction is possible. 114.111.151.60 (talk) 00:25, 13 December 2012 (UTC)

References, references, references. Please. --Nigelj (talk) 19:54, 13 December 2012 (UTC)

I would also like to throw in my two cents regarding this sorry article. Perhaps it's not the article that is at fault - Fielding's thesis is, in the words of another one of the people here, a prime example of the sorry state of academic publication in general. It could have been generated from a list of buzzwords using Markov chains. I think that waiting for a "serious academic source" to come out and say what anybody with eyes and a brain knows to be true is WISHful thinking as well. Emperor's new clothes and all that. Sukiari (talk) 19:55, 16 February 2013 (UTC)

Largest known implementation[edit]

The largest known implementation of a system conforming to the REST architectural style is the World Wide Web.

A modest assertion!

It is, of course, possible that a larger implementation exists, somewhere, which remains as yet undiscovered by humans.

RESTful web services[edit]

Methods by themselves are not idempotent. It is very common for people to use GET to do all sorts of non-safe things. By declaring a method as idempotent, you basically telling your users that calling the method repeatedly would give them the same result. So, what counts is the semantics implied with each method that counts. Back to PUT and POST, the only essential difference is that PUT should be idempotent while POST is not. However, not all updates are idempotent. If you use PUT for such situation, a user would wrongly assume that repeated PUTs would give them the same result but in fact it is not. In situation like this, POST should be used because it conveys the correct semantics.— Preceding unsigned comment added by 124.178.228.149 (talkcontribs) 00:53, 26 November 2010

Yes, that's the point of REST - not to redefine what HTTP methods are for. In a RESTful interface, all PUT actions must be idempotent and POSTs are not. People have been defining GET and POST to do whatever they like in web applications and RPC web services for years, and the point of REST is that we look up how the existing HTTP methods are defined and use them only as defined. If the developer feels free to decide whether a PUT or a POST is going to be idempotent or not, s/he is not designing a RESTful interface (which is what the article is about). --Nigelj (talk) 15:52, 26 November 2010 (UTC) P.S. Copied from my talk page in case others wish to comment too.

'Ordered sections alphabetically'[edit]

I just reverted a wholesale set of changes to this article made under the edit summary "Ordered sections alphabetically, improved formatting & made corrections". The main thrust of these was to reorder main sections of the article into alphabetical order, rather than the logical order that they were in derived from the cited sources, including Fielding's dissertation. There were other changes in this edit, and I hope that if Sae1962 believes that some of these other changes were more worthwhile, perhaps they'll come back here per WP:BRD and discuss their merits individually. An intervening edit by Carleas was also reverted, but this was only an attempt to fix a grammatical error introduced Sae1962's edit, so nothing is lost there. --Nigelj (talk) 20:52, 12 April 2011 (UTC)

One of the lesser web programming articles. :([edit]

This article breaks the trend of the excellent Wikipedia articles on Internet technology I have read so far. The intro does nothing but expand the acronym, and the article proper is... confusing to put it mildly. — Preceding unsigned comment added by 98.66.184.234 (talk) 04:01, 6 June 2011 (UTC)

Framework Implementations[edit]

I don't think that CodeIgniter counts as a framework implementation of REST. It might be possible to implement a REST architecture using CI but that would involve some fairly large deviations from the CI way of doing things. For example, the CI way discourages the use of GET query parameters and encourages you to put them in URL segments instead. The term 'REST' does not even get a mention on the CI project home page.TristramBrelstaff (talk) 13:09, 5 July 2011 (UTC)

Random list of examples of POX websites[edit]

I have tracked down a large unreferenced insertion that made into this article in this edit in August this year. It appears that there was a two-person discussion here and it went ahead without any mention on this talk page. The orphan article was already tagged as requiring 'cleanup', and was unreferenced apart from a bewildering array of inline external links, with no secondary or scholarly sources whatsoever.

The original article introduced itself, "Using a very loose definition of REST..." and the section we acquired begins, "There are also examples of interfaces that label themselves "REST", but are, in fact, [not]".

These subsections are completely unhelpful and bogus in their present form, and serve to do little more than to confuse the flow of the present article. I have removed them and they are reproduced below if anyone is interested in discussing the matter further. --Nigelj (talk) 20:30, 28 September 2011 (UTC)

POX/HTTP[edit]

There are also examples of interfaces that label themselves "REST", but are, in fact, using HTTP to tunnel function calls — also known as 'POX/HTTP', or Plain Old XML over HTTP:

Some of these interfaces do not intentionally respect REST's architectural constraints. Some have been called Accidentally RESTful, by Mark Baker, a REST expert. The accident of RESTfulness occurs primarily when standalone GETs are appropriate, i.e. when it's not appropriate to navigate through many GETs in hypermedia style, and when those GETs simply retrieve data and do not change it.

Static websites[edit]

Using a very loose definition of REST, it is possible to erroneously claim an enormous number of RESTful applications on the Web (just about everything accessible through an HTTP GET request or updatable through HTTP POST). Although it is theoretically possible to classify most or all static websites as REST "applications", it is debatable whether a static set of web pages constitutes an interactive application. Taken more narrowly, in its sense as an alternative to both Web service generally and the RPC-style specifically, REST can be found in many places on the public Web:

REST examples are not restful[edit]

Besides Atom, every example implementation listed here is just the usual RPC over HTTP. The Sun Cloud API which is supposed to be a "good example" is clearly just a HTTP+JSON API with the terms "resource" and "media type" sprinkled about. Their so called media types are tightly coupled to the application, right down to specific resource types and API versions. There is loads of documentation about resource types, their hiearchies, what protocol methods can be used on them, etc. It breaks just about every rule in the book. The other examples seem to be much the same thing.

The section "RESTful Web Services" also pretty much describes a non-RESTful service. It says "the API must be hypertext driven" but lists example representation formats that aren't even hypermedia. JSON does not have links or processing rules, aside from the rules for parsing it. Then it describes how to map CRUD to HTTP, which doesn't have much to do with REST. Jedediah Smith (talk) 09:47, 29 January 2012 (UTC)

The section on CMIP certainly does not help. CMIP is an ITU protocol that uses ASN.1 for message formatting that is not restricted to Basic Encoding Rules (BER). The very nature of the Agent-Manager relationship with the encoding / decoding of ASN.1 introduces a level of complexity that is very much a non-RESTful interface. CMIP was the Network Management protocol that caused Marshal T. Rose to break with the ITU Network Management initiative and develop SNMP. — Preceding unsigned comment added by 69.26.238.163 (talk) 21:17, 2 April 2013 (UTC)

Idempotent PUT[edit]

The article currently says (in markup) for PUT: "Replace the addressed member of the collection. If it doesn't exist, this will fail. <!--, or if it doesn't exist, create it. => NO, because PUT is idempotent which means the server does always the same action for the same request. If there is a creation for a PUT request, there will be no creation for the same request made just after which would make PUT non-idempotent. So: no creation for PUT! -->"

I don't have a ref at the moment, or any direct experience of this in practice, but I do know what idempotent means. Our own article on the concept says, "A unary operation (or function) is idempotent if, whenever it is applied twice to any value, it gives the same result as if it were applied once." Our article on HTTP says, "PUT: Uploads a representation of the specified resource." and "Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request." (My italics both times).

This is quite a different meaning to what has been added to the commented out section in this article's markup, where it says, "NO, because PUT is idempotent which means the server does always the same action for the same request." The contributor here, I think is muddling 'doing the same action', like simply running the identical piece of code, with 'having the same effect' and 'giving the same result', which are what idempotent means.

If I have a data record and I PUT it onto a REST server, I would expect it to be there after I'd done so. If I then accidentally PUT it there again, then I don't expect two copies. That is the idempotence: the server will ensure that if an object is PUT there, it exists, once. If I alter the object or data record, and PUT it again, then I expect it to be updated. In short I think the article text was correct before the comment markup was added, and is incorrect now. --Nigelj (talk) 00:08, 6 February 2012 (UTC)

Merge framework implementations list[edit]

I suggest merging #Framework implementations into List of web service frameworks and replacing the section with a see-also link. If there are no objections, I'll take care of it next week. —Pathoschild 14:52, 19 March 2012 (UTC)

  • Delete section This lists sprout up wherever there's a space, but they add nothing. What does it mean? What content does it convey? Does it say anything about the items listed?
This list really only makes sense under REST, so I oppose the idea to merge it elsewhere. Andy Dingley (talk) 14:59, 19 March 2012 (UTC)
I would agree with the merger request. I think that the Framework page includes more information, as well as the fact that the current list includes articles (like sales force) that don't really fit with the list. I think the framework article includes more information. Maybe reference it where it currently is in the page though, instead of a "see also" — Preceding unsigned comment added by Shaded0 (talkcontribs) 05:00, 5 May 2012 (UTC)
  • Merge into proposed list article as its not just a bunch of external links so fit list article. Widefox (talk) 10:07, 26 June 2012 (UTC)
  • Merge I suppose if we are going to have a list of these things, it would make more sense to have them near a web framework list. Iæfai (talk) 03:11, 1 September 2012 (UTC)

SOAP and WSDL replaced by REST?[edit]

I think this is plain nonsense. First, REST does surely not replace SOAP, as they can coexist without problems. Next, WSDL offers meta information about a SOAP service. I can't see where REST offers any meta informaton at all, so this comparison makes really no sense. It also left the raeder with the notion, that WSDL and SOAP are two different, but comparable things, which is not the case either. — Preceding unsigned comment added by 89.246.194.193 (talk) 15:41 UTC, 9 June 2012

Response by Ron:
I believe that REST is definitely replacing SOAP for most new applications because SOAP architectures are not usually designed to support occasionally-disconnected (e.g. mobile) clients. You can include any metadata you want in an XML or JSON message. It seems to me that a key point about REST vs. SOAP is that REST doesn't require the web service to handle typed parameters (formatted "stateful" buffers). In other words, it seems to me that typed data (vs. XML/JSON) requires a stateful web service to host the object type definitions (as described in WSDL, for example). A RESTful web service, to me, should simply pass a generic request payload (typically XML or JSON) to a separate process (e.g. database or application code). It seems to me that a RESTful web service process should not include business-specific or application-specific code, but instead it should be a dumb endpoint and conduit that only understands how to receive the request and pass it to another separate process. This seems to me the only way to achieve total separation of UI and "state" as represented by a collection of durable data repositories. I also do not subscribe to an assertion that REST requires the use of URI hierarchies. I think it's equally valid to have a single URI to which you can pass different types of XML or JSON messages. The payload can then describe the purpose and/or routing of the request, which the RESTful web service can parse the message to ascertain. This is how most of the RESTful APIs I use work (e.g. Salesforce.com) — Preceding unsigned comment added by 72.130.8.151 (talk) 23:08, 30 July 2012 (UTC)

Disagree. The absence of typed parameters in your description of REST is an illusion. The payload must be interpreted by the server, and improperly formatted payload will likely lead to errors. I don't see how this can possibly be distinguished from a remote API, and the efforts in the article to do so strike me as misguided. 98.216.48.55 (talk) 12:22, 3 June 2013 (UTC)

So what next?[edit]

In my opinion there is a lot of experience exposed here (I learned more from the discussions than from the article itself). As the article is still unclear to me, we could vote for certain paragraphs or content. Like ¨REST is always HTTP¨, ¨PUT imdepotently will always have the same effect¨, ¨BLA¨. I´m sure the best article is a mix of what is mentioned above. Then, if we have a set of statements about REST, we could explain that in the industry, or in academia, there are opinions whether X means Y. Does this make sense? We´re not far off a war if I read between the lines (as a NL reader). Wezkoh (talk) 15:08, 8 October 2012 (UTC)

New references[edit]

Please add what you can to the list below. This article needs attention, and to make it better we need to start with better, more up to date, more user-oriented and business-oriented references (as well as the existing emphasis on the architectural style itself as described in Fielding's thesis). We need university-level textbooks and other dispassionate, third-party, secondary sources. We do not need any more 'Web 2.0' buzzword soup, or any breathless marketing blurb about some startup's new REST API. --Nigelj (talk) 14:06, 26 July 2012 (UTC)

A Proposed Content Plan[edit]

This is a terrible article as it currently exists, and the commentary here is not leading in the right direction. Most of the article is full of spurious references as well as an illogical mixture of concepts, such as the contrasting of a constraint model with a protocol. For example, SOAP is a specific protocol with concrete documentation. REST is a set of architectural constraints designed to qualify particular protocol instances as being conformant.

I suggest a breaking down this article into more meaningful sections, collating the original information, and rewriting the article as follows:

  • Definition
    • REST is a set of design constraints first proposed by Roy Fielding in his 2000 disseration "Architectural Styles and the Design of Network-based Software Architectures".
    • To conform, Fielding proposed that an interface be client-server, stateless, respect caching, have a uniform interface, exhibit the characteristics of a layered system, and optionally support a code-on-demand model.
    • REST has been employed informally throughtout the software industry and is a widely accepted set of guidelines for creating stateless, reliable web services.
    • The term RESTful is often used to describe interfaces which conform (more or less) to the various interpretations of Fielding's proposed constraint structure.
  • History
    • Provide an abstract of Fielding's original dissertation.
    • Indicate how the W3C has adopted the term REST within various specifications, giving it credibility.
    • Indicate the current situation, where REST is an informal set of constraints subject to interpretation with no clear established definition which is agreed upon by all practitioners.
  • Interpretations - Contrast each interpretation of REST
    • Fielding's original
    • While not specifically part of Fielding's recommendations, REST is often interpreted as a mandate to use specific HTTP transaction methodologies. Describe this here.
    • Other interpretations
  • Practical applications of REST
    • HTTP GET/PUT/POST
    • SOAP (Despite the fact that many are biased against SOAP, RESTful interfaces can be implemented using almost any protocol, including SOAP. Finding examples would be good.)
    • XML-RPC
    • etc.
  • Criticsm
  • References

Obviously, there is a tremendous amount of work to be done. However, REST is a term used so frequently, that Wikipedia should be a beacon of clarity, not yet another confused mess of opinion and vague terminology.

If the above were undertaken, it would be important to acknowledge:

  • That REST is a set of constraints (or design patterns), not a protocol. It is subject to interpretation.
  • Futher work is required to establish an agreed-upon set of best practices.
  • Protocols such as HTTP, SOAP, XML-RPC all exhibit some characteristics of RESTful interfaces to various degrees. This should be explored and well-defined.
  • Constant diligence is required to assure that terminology throughout is consistent, logical, and does not make comparisons between unrelated concepts.

GaryWisniewski (talk) 07:07, 5 March 2013 (UTC)

I thought the point of REST was to make it simple. — Preceding unsigned comment added by 62.194.127.42 (talk) 19:42, 11 April 2013 (UTC)
I second this proposed plan. A major rewrite is needed. How is that done; do we flesh it out in the talk page or what? Mogsie (talk) 21:38, 4 May 2013 (UTC) (or perhaps by drafting a page on my user page... hmmm. Mogsie (talk) 21:48, 4 May 2013 (UTC))
I like the plan. Be bold and go for it. Pasado (talk) 03:39, 30 August 2013 (UTC)
I like this outline. Coming to the article with no idea what REST means, the introduction should have illuminated me, not dicouraged. http://searchsoa.techtarget.com/definition/REST has a good definition in plain English ~~

Gateways part of the web?[edit]

Please explain how gateways are part of The Web, otherwise this sentence must be corrected.
Quote: "by characterizing and constraining the macro-interactions of the four components of the Web, namely origin servers, gateways, proxies and clients"

Gateways are part of the Internet at the 3rd layer (the network layer) and the Web exist at the application layer. How can they be part of The Web? — Preceding unsigned comment added by Hrgwea (talkcontribs) 04:01, 30 April 2013 (UTC)

Good point. See below. --Nigelj (talk) 19:14, 4 May 2013 (UTC)
The web is an application, but this has also encouraged the development of web services. Within these, "the web" is now acting as a transport layer, not an application. Andy Dingley (talk) 19:44, 4 May 2013 (UTC)
Yes but the original poster was asking whether gateways are actually one of the components of 'the web'. I say they are not, and further that talk of "characterizing and constraining the macro-interactions" of gateway servers is virtually meaningless as a helpful description of REST. Hence the section I started below. --Nigelj (talk) 13:13, 6 May 2013 (UTC)

Random collection of unreferenced assertions[edit]

I think the About section has started to become a place where people have felt free to add a line here or there that represents what they may feel is a great personal insight into the 'real nature' of REST. Of course these are not referenced. I have removed two bits of this kind of text here. I don't see how these sentences can either be justified, or how they fit in with the rest of the (referenced) parts of this article. If anyone feels differently, please supply the relevant WP:RS citations as you re-add them.

REST exemplifies how the Web's architecture emerged by characterizing and constraining the macro-interactions of the four components of the Web, namely origin servers, gateways, proxies and clients, without imposing limitations on the individual participants. As such, REST essentially governs the proper behavior of participants.

REST facilitates the transaction between web servers by allowing loose coupling between different services. REST is less strongly typed than its counterpart, SOAP. The REST language uses nouns and verbs, and has an emphasis on readability. Unlike SOAP, REST does not require XML parsing and does not require a message header to and from a service provider. This ultimately uses less bandwidth. REST error-handling also differs from that used by SOAP. Predominantly the use of SOAP is to invoke behaviors while REST invokes information.

--Nigelj (talk) 19:03, 4 May 2013 (UTC)

Constraints[edit]

FYI: I will be building out the Architectural Properties and Constraints sections over the next few months. Pasado (talk) 18:35, 21 November 2013 (UTC)

Inconsistent[edit]

In the ingress "The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation at UC Irvine." and later "Fielding used REST to design HTTP 1.1 and Uniform Resource Identifiers (URI)." The docs used as reference for the last sentence is written before 2000 and thus the first sentence must be wrong. Perhaps he only coined the term REST in the doctoral dessertion, but then the last sentence is somewhat misleading. Jeblad (talk) 09:08, 23 January 2014 (UTC)

I see no obvious contradiction here. The is a principle behind REST and the term REST itself. One obviously pre-dates the other. A significant use of it in HTTP may even pre-date its recognition as a distinct concept. AFAIK, there are no published uses of 'REST' prior to his dissertation. The REST-like behaviour of HTTP is clearly published long before this. His dissertation was in effect to recognise that there was some useful underlying principle at work in HTTP (not even claiming this to be a novel principle), to codify the behaviour of this principle and also to coin its name. The RFCs are an easy source to check to see if there are earlier uses of the term REST, but I expect you to find many descriptions of it pre-2000 without the name itself. Andy Dingley (talk) 11:08, 23 January 2014 (UTC)

Introduction Section Is Confusing[edit]

I am a software engineer and was looking for a clear, concise, easy-to-understand summary of what REST is, came to this wikipedia page, and found the introduction section to be incredibly confusing - especially to a layperson. I looked through the talk page and found a few comments about how confusing the introduction section for this article is, but I think this topic is important enough to have its own section on the talk page. Here's the current first sentence of the introduction: "Representational state transfer (REST) is an architectural style consisting of a coordinated set of constraints applied to components, connectors, and data elements, within a distributed hypermedia system." I'm sure that definition is super duper correct, but correct doesn't matter if it's difficult to be understood by someone unfamiliar to what REST is - which is probably who would be coming to wikipedia to look up REST - like me. I wish I were a REST expert so I could rewrite the introduction, but I'm not. I'll try to do some research (the links in the "New References" section above are looking very promising!) to find some good sources for a better introduction, but, in the mean time, could someone knowledgeable on the subject who can also communicate well and in simple and concise ways take a stab at a rewrite. Perhaps you could post it here in this talk page section first and we can tweak it before putting it in the main article. I think if we can start with a good introduction, we'll have a better foundation for making the rest (pun) of the article more understable. What think ye? Rcronk (talk) 23:22, 10 February 2014 (UTC)

I think the first sentence is precisely correct, but is confusing because it uses terms (components, connectors, and data elements) without definition. So I added a Software architecture section to define the terms. I hope that helps. Pasado (talk) 18:54, 12 April 2014 (UTC)

Commented-out article text[edit]

The following text is commented out in the body of the article.

Steve Vinonski (Vinonski, 2008) describes the effect on the Web if the uniform interface constraint was to be violated:

Imagine, for example, that the Web comprised millions of Web sites and that each defined its own special interface. To use your Web browser to interact with a particular site, you'd likely need to download or write a new browser plug-in that understood that sites interface. Admittedly, I've exaggerated the problem to make its effect clear, but there is no question that the uniform interface constraint can allow for more highly scalable systems. It removes the entire interface contract term from the client-service interaction equation.

Vinoski (Vinonski, 2008) also emphasized the importance of the uniform interface in the context of serendipitous reuse. Serendipitous reuse means re-using Web services beyond the scope originally conceived by the provider. Concrete examples of serendipitous reuse of Web services can be seen in so-called mashups. He states that highly specialized interfaces, such as typical WSDL interfaces, inhibit the likeliness of a service to be serendipitously re-used. WSDL exposes for each interface a unique vocabulary, thereby complicating the semantic knowledge for intermediaries and clients. Given this definition, serendipitous reuse can thought of as service reusability (one of the key principles of service design). He puts this as follows:

The more specific the service interface, the less likely it is to be reused, serendipitously or otherwise, because the likelihood that an interface fits what a client application requires shrinks as the interface’s specificity increases. Highly specialized interfaces inhibit general reuse because only purpose-built clients can invoke them. Should requirements change—and they will—modifying such highly specialized services and clients to fulfill the new requirements can be costly because of the high degree of coupling between them.

I think we need to decide whether to delete this or to re-instate it. It is not normal for large chunks of text to remain commented-out in the body of an article without any discussion. FWIW, my vote would be to delete it. --Nigelj (talk) 22:46, 13 April 2014 (UTC)

I agree and done Pasado (talk) 19:05, 20 April 2014 (UTC)

Concept sub-section: Vocabulary re-use vs. its arbitrary extension: HTTP and SOAP[edit]

This sub-section strikes me as far below the standard of most of the rest of the article. Whilst I felt I was gaining understanding from the preceding material, when I hit this I found it merely confusing. For example, is SOAP an alternative to HTTP, or is it an alternative to REST? The text doesn't seem to be able to decide.

I am tempted to simply delete this sub-section, but since someone must have felt it to be important, maybe it could be improved instead.

I too have been tempted to delete this sub-section. So I just did. Pasado (talk) 19:14, 20 April 2014 (UTC)

The first sentence[edit]

The first sentence starts currently: "Representational state transfer (REST) is an architectural style...". That, to me and I suspect to many other readers, means that REST is something like Gothic, Rococo or Brutalist: a style in which buildings are made. Wouldn't it be preferable to start by saying that it's something to do with computers? I think this really matters, so I'll make a change now, but someone may be able to improve on my wording. — Preceding unsigned comment added by 213.162.107.11 (talk) 17:37, 15 April 2014 (UTC)

Good catch! REST is a software architectural style. So I changed the first sentence to say so. Pasado (talk) 19:30, 20 April 2014 (UTC)


Cite error: There are <ref> tags on this page, but the references will not show without a {{reflist}} template (see the help page).