Talk:Representational state transfer

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

Friendlier opening paragraph[edit]

I made a start to try to introduce the topic in a less techno-dense way. It probably could say more but unless I'm telling an actual lie, please don't revert or change it back to "incredibly technical". Ordinary people (eg scrum masters) might like to know what REST is. Aelfgifu (talk) 10:38, 24 August 2016 (UTC)

The opening paragraph starts with "... representational state transfer (REST) or RESTful is an architectural style ...". RESTful should be removed, in my opinion. "REST" and "RESTful" are not the same, the same way "art" and "artful" are not the same. At the end of the first section, RESTful is correctly defined: "To the extent that systems conform to the constraints of REST they can be called RESTful". So, again in my opinion, RESTful should be dropped from the opening line. I would have done it myself, but since I see there are people more involved than me in looking after the page, I just mention this here. (talk) 09:44, 29 September 2016 (UTC)
What is the difference between REST and RESTful? There is a slight grammatical difference but the two terms are used interchangeably within the software field. Accordingly an encyclopaedia article should list both in the lead. Andy Dingley (talk) 09:50, 29 September 2016 (UTC)
Nigelj fixed it. Now it reads "... RESTful web services is an architectural style ...", which is grammatically correct. It might be a technical subject, but grammar is always important. Imagine saying: "Your RESTful is not standards compliant". What does it mean? Your restful API? Your restful programming? Your restful service? RESTful is an adjective. (talk) 13:54, 29 September 2016 (UTC)

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: 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: (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:

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. (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)


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. (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 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 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)


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)


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. (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 (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)


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, "" 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... (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).

Resources—Commands are defined in simple terms: resources to be retrieved, stored / get, set—difficult to do many joins
Commands—Commands are defined in methods with varying complexity: depending on "standard"—easier to hide complex things behind a method
Nouns—Exchanging resources and concepts
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)


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 (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 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: 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. (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

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

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)


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 (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)
I have actually used CICS pseudo-conversational mode as an example for what a RESTful interface would look like/is trying to achieve; but the analogy isn't precise. CICS doesn't have 'GET', 'PUT, etc. It only has 'SEND' and 'RECEIVE'. The screens are effectively stateless, but the application it is speaking to is not, and the invoked application code is responsible for determining the intended operation (usually by examining which transmission key was pressed). Nonetheless, with those caveats, CICS pseudo-conversational mode looks an awful lot like the description of RESTful interfaces. William J. Lightner (talk) 14:39, 17 April 2015 (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)


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[3] 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. (talk) 15:47, 17 May 2010 (UTC)

obvious troll is obvious. please try making a point next time, douchebag —Preceding unsigned comment added by (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. (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 (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 (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" you do "DELETE". 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! (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. (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. (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)

I'm not sure if the article was rewritten after these comments, but it is still just a chain of Jabberwocky statements that mean nothing to anyone but have enough grammatical structure to resemble statements with meaning. Analyzing each sentence would be straining for this discussion, so I'll use only this one as an example: Performance - component interactions can be the dominant factor in user-perceived performance and network efficiency. First, what is "performance" here? I've encountered several meanings, but in the context of programs and users running those programs, performance is usually the quality of a program to respond to the input and conditions under which it is run in a way which is consistent with the previously advertised properties of the said program. For example, a user may expect that the program that lists the contents of directories will perform in time linear to the number of files in listed directory. This makes it possible for the program to under- or over-perform (by listing files quicker or slower). Now... what is component interactions? -- Well... it's everything... everything can be described as a component of something else... anything that happens anywhere can be described as component interactions -- what other kinds of interactions are there? So, what is this performance a property of? -- From reading the paragraph, I get no clues. Why is it user-perceived? Who else might be perceiving this performance? Why does it matter if anyone perceives it? (In my understanding, performance is independent of whoever perceives it. It is described in terms of the contract the program makes about its input and running conditions, observed or not -- doesn't matter). Finally, and network efficiency: is network efficiency an artifact perceived by user, or is it a product, of which performance is the dominant factor? I guess, we'll never know. Though, more importantly, how is it different from whatever user-perceived performance is? Couldn't it be a subset of performance? Why don't users perceive network efficiency? My conclusion after reading this sentence: "blah-blah-blah". No meaning what so ever... (talk) 12:58, 14 November 2017 (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.

Given REST was derived from the web architecture, saying the web conforms to REST is void of content. The only thing it states, is that the web is the largest implementation of the web. It doesn't prove fitness for any other purpose than "designing the web", nor it proves the merits of a supposedly generic architectural style for machine-to-machine API design (remember, the client side of the web has a human attached to it, which is a pretty big assumption for a machine-machine API design). — Preceding unsigned comment added by (talk) 14:55, 9 March 2015 (UTC)

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 (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 (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)


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 (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 (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. — Preceding unsigned comment added by (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. (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
    • 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 (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. 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)


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)


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 (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)

Example REST URIs[edit]

There have been a few edits to change the URIs in the tabulated examples in this article. Fielding's thesis Chapter 5 does not give any example URIs, but several knowledgeable developers and bloggers have published extensive examples on the web. I couldn't find any that matched recent suggestions here, but the following are a few that use the format we have used. (At the moment, I'm only looking at examples of GET, collections, and individual items of the collection)

    • GET /foos/{id} # read a Foo
    • POST /foos/{id} # create a Foo
    • PUT /foos/{id} # update a Foo
    HTTP/1.1 201 Created
    Location: /api/carts/323392
    /conversations : all conversations
    /conversations/conversation-{id} : a specific conversation
    /conversations/conversation-{id}/todo-list-{id}/todo-{id} : e.g. a todo item on a todo list on a particular conversation
    Advantages: hacking the url by removing a path will give you the todolist, the whole conversation, or a set of conversations
    At RedRata we are opting to use this plural-name-and-id template for nested resources.
    • /posts/1
    • GET /transactions/1 HTTP/1.1
  5. (Slide 57)

--Nigelj (talk) 22:12, 31 July 2014 (UTC)

Adding more URI examples[edit]

I would like to include more detailed information on this page regarding RESTful HTTP applications & URI resources. Some of this information is fairly standard (even if there is no RFC/ISO for it). Ruby on Rails has one implementation of this popular style, this is by no means cited from their work. I have a draft of this section on my sandbox page. One caveat about my sandbox, the information does need some more narrative explanation, as it is currently just specifications and examples. Please advise.

--Hawleyal (talk) 20:02, 31 August 2014 (UTC)

This isn't just for me to review and decide upon, so I have adjusted the section heading to be more general. I already reverted an addition similar to what is proposed. Personally I don't think we need this level of detail of specific examples, and as I said in the edit summary when I reverted, most of the new jargon that is introduced in these tables seems to me to be at least Ruby-specific, if not Ruby-invented (e.g. "7 basic routes" and "form for editing specific article; GET; /articles/{id}/edit"). The information as it stands in the sandbox is completely uncited, and it is impossible to know whether it consists of examples of good practice, suggestions, or lists hard-and-fast requirements for an implementation to be considered RESTful (which it does not). It leaves unanswered many questions about alternative languages, internationalisation, alternative approaches and places great emphasis on trivial points without explaining the reasoning, such as whether /security_groups or /securityGroups are ever acceptable compared to /security-groups for example. What do other editors think? --Nigelj (talk) 22:21, 31 August 2014 (UTC)

Layman's summary[edit]

An IP editor recently added a 'layman's summary' to the top of the lede, that was quite rightly reverted, as there are strict WP:MoS style guidelines for how an article must begin. On the other hand, the page is tagged 'too technical' and we are admonished 'to make it understandable to non-experts.' Reading the opening lines, and imagining oneself to be, for example a departmental manager, or a business customer, who has been talking to 'the web guys', who have been talking earnestly about needing just a few $100,000's to build the business a new REST interface, well, it isn't much immediate help. I wonder if there is something to salvage from this text, and to put in before we get onto 'abstractions of the architecture' and 'hypermedia', just to help such a reader?

layman's summary: This is used to allow programs to interact with a companies data or other computer services through a web-based interface. It allows a company to create a service then have others "extend" that service in ways that they perhaps have not thought of or have not gotten around to yet.

The only potential source I have found in a quick search is this one. Does anyone have a better source, or an eye for the right synthesis? --Nigelj (talk) 23:03, 10 December 2014 (UTC)

I didn't even notice the tag when I reverted. I did a quick Google Books search, and found REST API Design Rulebook by Mark Masse. Pages 2-5 describe REST and the web architecture on which it operates. Mindmatrix 23:20, 10 December 2014 (UTC)

Contradiction in Introduction[edit]

'REST is an architecture style or design pattern used as a set of guidelines for creating web services' vs 'The REST architectural style is also applied to the development of web services.'

REST is only for web services, not also for web services. — Preceding unsigned comment added by Buchs (talkcontribs) 13:56, 11 January 2015 (UTC)

I cleaned up the lede a bit, but the distinction between REST as an abstract architectural style and REST as a set of guidelines for creating web services is still unclear throughout the article. I agree that REST, as most people encounter it, is specific to web service design, and if that's the consensus we should try to make things more concrete. ~jenrzzz (talk) 07:54, 20 January 2015 (UTC)

REST is an architectural style. One applies this style to a problem, like building HTTP 1.1. It was initially it was used to develop HTTP 1.1. The REST architectural style is also applied to the development of web services so that those services can gain the benefits of that architectural style. Pasado (talk) 01:09, 12 June 2015 (UTC)

Split proposal[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result of this discussion was No Split

This article is supposed to be about Representational State Transfer (the abstracted architectural style of the world wide web). The introduction had a strong relationship to the content of the rest of the article in early January. Now it's conflicted. To me this signals the need to create a separate article for RESTful APIs (the application of that style to APIs). This would allow us to give the needed focus to this important topic. Pasado (talk) 08:51, 13 February 2015 (UTC)

  • Don't split. I don't see a need to split the article on this basis. WP:SPLITOUT recommends two reasons to split articles - either they are too big (>~50KB of readable text and this article is only 16 KB in total), or that they contain two or more distinct topics with a similar, ambiguous name ("such as "light", which may refer to electromagnetic radiation, a component that produces light, or spiritual illumination"). If Pasado (talk · contribs) has something in mind to say about RESTful APIs, then maybe they could add a section to the existing article showing what is intended, or start a sandbox or userspace mockup article to show us what they have in mind. Personally, I'm worried that it might have the form of a list of links to existing REST services, or be largely based on developer documentation from, for example, Ruby on Rails or similar API guidelines. In either such case, I think that the fact that the internet is much bigger, uglier, and more diverse than anything anyone can imagine would be the ultimate downfall of any such plans. --Nigelj (talk) 11:50, 13 February 2015 (UTC)
  • Don't split. Please — Preceding unsigned comment added by (talk) 08:20, 17 February 2015 (UTC)
  • Oppose. Don't split. From reading further abroad in the (still confusing) literature, it appears that RESTful API is something of a religious hot-button to some parties involved in the identification and adoption of the technology. Splitting the topic does not appear to really help with the matter. And there is some educational value to addressing the issue within the confines of this topic, rather than attempting to isolate the topic.William J. Lightner (talk) 14:43, 17 April 2015 (UTC)
  • Oppose See Wikipedia:Article size and Wikipedia:Splitting. The article is not long. The content would not be sufficiently different to require a new article. There is no need for the article to be split. (talk) 22:04, 23 April 2015 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Proposed merge with Overview of RESTful API Description Languages[edit]

There was a recent discussion about splitting off RESTful APIs as a separate page that I closed as no split. Having a separate page on just the description languages (to say nothing of the very odd name for this page) makes even less sense. Wieno (talk) 06:18, 10 May 2015 (UTC)

No. Dragging in material about description languages goes off topic more than reorienting this page to be about an APIs. Pasado (talk) 01:13, 12 June 2015 (UTC)

No. Per WP:OTHERCRAPEXISTS, if there's an article somewhere else that makes no sense, and has an odd name, the best place to discuss those problems is on that article's talk page. This one is fine as it is, so far, thanks. Feel free to try to improve it if you find something good and well-referenced. In the meantime, I'm going to remove the tag about this: It hasn't been discussed for months, and it clearly wasn't going anywhere anyway. --Nigelj (talk) 16:21, 17 August 2015 (UTC)

The introduction feels like a top down description. Let's try bottom up.[edit]

An intelligent ignoramus, like me, might prefer that the initial definitions are written for some one without the jargon of the domain in question. So, by top down it feels like some one has taken a computer science definition of REST and condensed it. Bottom up would be here's the reasons people use it. "It solves problems of this nature." IE talking about the answer to the "So what?" question. Lets have a section about the benefits as well as the features.

For instance "coordinated set of constraints to the design of components in a distributed hypermedia system". My guess would be that there are very few human beings who do not know about REST but would understand that sentence. The definition and description are written from a knowledgeable view point (top down) not from the viewpoint of an interested learner.

I would propose that we rewrite this and some of what follows it In computing, representational state transfer (REST) is the software architectural style of the World Wide Web.[1][2][3] REST gives a coordinated set of constraints to the design of components in a distributed hypermedia system that can lead to a higher-performing and more maintainable architecture.

to say something along the lines of

REST named from - REpresentational State Transfer - is an approach to writing software for the world wide web. It is the default method for developing most Web and mobile apps[1].

Unlike many other approaches to software production REST assumes that many different computers joined by the internet will collaborate and communicate to complete a desired task and that there may be great variability in the speeds and capability of the computers and their internet connections. The tasks may be as simple as displaying a webpage or delivering an interactive game to a phone.

It is valued on the web because

  1. a service provider like a web site doesn't need to update the browser to change their site.
  2. The service provider doesn't have to worry about what browser is being used; phone or desktop for instance
  3. The service provider and end user can both update their devices without worrying about the other.
  4. The program's tasks can be relatively easily split among many different computers allowing big tasks to be shared more readily allowing improved performance.
  5. This splitting allows services to be split - the rules for how a site looks can be stored and maintained by a different supplier than the content producer.
  6. it is reliable despite the the intermittent failures of communication typical of the internet.

It is valued by programmers because

  • it offers a relatively simple programming approach,
  • allows the communications between computers to be securely but easily monitored if needed,
  • it allows both data and programs to be sent together so that changes and improvements can be delivered without the need for upgrades,
  • it allows significant changes to the functionality the programs, again without the need for upgrades.

REST can also be challenging to writ "adapting rich server behavior into the uniform HTTP interface can be confusing and at times appears pedantic in comparison to the relatively straightforward RPC approach." [2]

REST is often compared to other client server approaches especially SOAP.

Dickwall (talk) 21:30, 11 December 2015 (UTC)Dickwall

What's missing here is a set of citable references that meet WP:RS. If you can find reliable sources that introduce REST in this way, or something similar, we'll have something to work with. (I took the liberty of adding some wiki markup to your comment to make it lay out closer to what I think you intended - wiki software takes consecutive lines as all being part of the same paragraph, needing a double line-space to demark an actual paragraph. It seems that you intended lists, not paras anyway.) --Nigelj (talk) 16:43, 1 February 2016 (UTC)


What is a "coordinated set of constraints"?[edit]

I think the term "coordinated set of constraints" does not make sense in standard English. I suspect that it simply means "a consistent set of rules," but Fielding wanted to call it "coordinated set of constraints" because of some (legitimate) technical meaning - yet, in the introduction of a WP text, we should use common language as far as possible. --User:Haraldmmueller 14:44, 1 February 2016 (UTC)

Whatever we think he meant, I'm afraid we have to stick with the sources. If you have a less formal but still reliable source that explains what this phrase means better than Fielding did, please give us a link, and we can do something with it. --Nigelj (talk) 16:46, 1 February 2016 (UTC)
Well, if we understand what the source(s) mean(s), we can of course rephrase that so that it can be understood (at all or more easily) ... I'll look into the dissertation; and when I think I know what it means check a little bit with his blog and other remarks - there, he sometimes tries to explain his text; at least for one aspect (media types) he claims here that he did not have enough time to explain it in his thesis ... well, then, small wonder people have to guess what he means ... --User:Haraldmmueller 18:31, 1 February 2016 (UTC)
Using your understanding to rephrase anything is WP:OR and using information from one source to interpret another is WP:SYNTH. You are not allowed to do either. TvojaStara (talk) 11:04, 4 February 2016 (UTC)
It was almost certain that someone would react like that :-). You, whoever you are, are not allowed to "not allow" me something - this violates about a dozen "rules" of WP, e.g. "Newcomers apparently trying to edit in good faith should be supported, not "bitten".". Moreover, my factual knowledge about CS is certainly not to be disputed by you or anyone else upfront - of course, you can, if I have edited something, criticize it (and call it "interpretation") and revert it and change it etc.etc. Yet, WP is not and never founded on the principle that we only can use verbatim content from a secondary source or (as in this case) a primary source (which is, anyway, something which, also according to some rule I'd have to look up, WP frowns upon .... Have a good time, and dont't, please, try to police people if they just try to discuss something which obviously is problematical. Cheers! --User:Haraldmmueller 11:17, 4 February 2016 (UTC)
You are correct, this is WP:PSTS and WP:WITS. Wikipedia is a tertiary source (every encyclopedia is) and therefore it should rely on sources one level below (secondary). It works the other way too, researchers writing papers should not cite Wikipedia, but other papers or monographs (secondary sources) (unless there is a specific point in referencing WIkipedia, of course). I am giving you a taste of the frustrating backlash you may get after trying to clear the article up using a primary source, your own knowledge of the area and common sense. Anybody can then stand up and oppose you on WP principles. If they keep reverting you, it is the same as "not being allowed" to do it in the first place. I know what I am talking about, I am currently being similarly policed regarding a different topic. TvojaStara (talk) 12:16, 4 February 2016 (UTC)
Thanks for your cool-headed response! - running out of time (at OOP 2016), I did not research the topic anyway ... but I might find time in the next days; and then I'll try some modification/addition, but I promise to tread carefully ... --User:Haraldmmueller 14:03, 4 February 2016 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Representational state transfer. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

☑Y An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 20:56, 31 March 2016 (UTC)

'Technical' tag[edit]

I see that the article has been tagged {Technical} since last month. I don't see any discussion here. I'm planning on removing the tag soon unless someone can think what it is we're meant to be discussing or fixing. I agree that the article is about a technical aspect of the way some complex software works, but I think that it makes a pretty good job of introducing the topic in the opening paragraph, indeed saving a description of what REST actuaply consists of until the second paragraph. --Nigelj (talk) 14:32, 26 September 2016 (UTC)

If the tag hadn't been there, I might have added it. The concepts of caching & layers are understandable. Other parts aren't so clear. For example:
  • "Technically, REST consists of a coordinated set of components, connectors, and data elements within a distributed hypermedia system, where the focus is on component roles and a specific set of interactions between data elements rather than implementation details."
  • "The architectural properties of REST are realized by applying specific interaction constraints to components, connectors, and data elements."
  • "Except for simple fixed entry points to the application, a client does not assume that any particular action is available for any particular resources beyond those described in representations previously received from the server."
These are taken out of context, granted, but they're not much clearer in it. The sentence beginning "Reading the opening lines..." in your comment from a couple of years ago (in "Layman's summary", above) still seems applicable. BlackcurrantTea (talk) 08:40, 27 September 2016 (UTC)
OK. I've had a go at making the lead section more readable and less technical. I have based what I wrote on material from the W3C working group note on Web Services Architecture (cited), and on basic explanations from our own web service and web resource articles, plus some of the key points from the article body itself. I have removed the first of BlackcurrantTea's egregious examples above, and tried to clarify the rest of the existing lead. I hope this is a move in the right direction. --Nigelj (talk) 13:09, 29 September 2016 (UTC)
Definite improvement. That's a lot more understandable. I don't know that I'd have taken the technical template off just yet considering the Uniform interface section, but I don't feel strongly about it. BlackcurrantTea (talk) 14:25, 29 September 2016 (UTC)
OK. I've had a go at the other two points you raised above. I hope people think that these changes are keeping the right information, but using simpler language. If there are any more stumbling-blocks, please do let me know. I've got a few of the refs back into my head now, and I know my way around the article, so it's a good time to fix things. --Nigelj (talk) 15:20, 29 September 2016 (UTC)

Dismal condition[edit]

Stack Overflow post REST vs. RPC in PHP claims this article to be "in dismal condition". Is that still the case? --Mortense (talk) 09:05, 11 December 2016 (UTC)

That's a comment made in 2009 on a discussion thread that was closed in 2013 as 'unproductive.' Why don't you read the article and tell us? If you know of any reliable sources please use them to help improve the text. --Nigelj (talk) 10:29, 11 December 2016 (UTC)

Controversy: did the usage of the term shift recently?[edit]

Many people around me think REST is just RPC or any other API over HTTP. Only few know about GET idempotence, hyperlink discovery of resources, fixed entry points and other things... but those who do are very adamant in their stance what REST is and what is not. Regardless, the term apparently shifted towards more general usage and is now used to describe a broader range of applications. I mentioned it in the article briefly, but I think the controversy deserves more proper description, maybe even a whole paragraph on "recent usage". Any idea how to write it without causing a flame war between REST liberals and REST purists? --Šedý (talk) 16:39, 2 May 2017 (UTC)

"REST liberals" is an interesting way to describe "people who don't understand it, but like using buzzwords". Such groups are far from unusual (I had someone today complaining of "URI" being a misprint for "URL"). Andy Dingley (talk) 16:45, 2 May 2017 (UTC)
This article is about REST if you ignore the introductory paragraphs. I've tried to keep the introduction about REST but the API over HTTP crowd kept changing it. There is a section called "Applied to Web services" for them to expand. But in the years I've been working with this article they seem to not care to edit past the introduction.
Also, if REST is API over HTTP what is the architecture of the world wide web called? Pasado (talk) 23:02, 29 May 2017 (UTC)

Article could really use more of an example early on and less of a giant wall of text[edit]

I was explaining to an intern what REST was and I thought I'd send them this but holy crap this wouldn't be helpful. Early on in the article it should show an example where a get or post is called and some JSON is passed. Yes I know that technically it doesn't have to be and bla bla bla bla but in "basically what is it and how are people using the term" REALLY early on (like most other comp sci articles) it should have this. I'd add it myself but I've learned that articles with long talk pages are best not edited because some opinionated person will start an edit war...Just consider "would this actually help explain this" if someone asked "What is REST?" without already knowing it basically...and "what would make it actually work for that?" and I think you'll see what I mean Reboot (talk) 15:20, 22 May 2017 (UTC)

Are you thinking of AJAX? --Nigelj (talk) 14:52, 23 May 2017 (UTC)
Apparently you talking to your intern about Web APIs and for some reason you were compelled to inject the term REST. Pasado (talk) 23:23, 29 May 2017 (UTC)


Since the e in REST does not represent a word, should it be written ReST? — Preceding unsigned comment added by (talk) 13:57, 8 May 2020 (UTC)