Talk:REST/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

'Ordered sections alphabetically'

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

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

Framework Implementations

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

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

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

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

POX/HTTP

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:

• Amazon.com offers a "REST" version of its main 'E-Commerce' developer interface;
• eBay offers a "REST" developer interface;
• Facebook offers a "REST" developer interface NOTE: Facebook is in the process of deprecating its REST API [1].
• Yahoo! offers a number of "REST" developer interfaces.
• YouTube offers a number of "REST" developer interfaces.
• Truveo video search engine offers "REST" developer interfaces.
• NewsCloud offers a number of "REST" interfaces.
• movideo offers a number of "REST" interfaces.
• Microsoft SharePoint version 2010
• Microsoft Live Offers a "Rest" API [2].

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

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:

• The 'blogosphere' — the universe of weblogs — is mostly REST-based, since it involves downloading XML files (in RSS, or Atom format) that contain lists of links to other resources;
• OpenStreetMap offers a REST interface;

Idempotent PUT

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

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 (talk • contribs) 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)

So what next?

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)

REST examples are not restful

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

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

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

Random collection of unreferenced assertions

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)

Gateways part of the web?

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 (talk • contribs) 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)

SOAP and WSDL replaced by REST?

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

Response by Ron:

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

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

A Proposed Content Plan

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

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

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

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

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

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

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

I thought the point of REST was to make it simple. — Preceding unsigned comment added by 62.194.127.42 (talk) 19:42, 11 April 2013 (UTC)

I second this proposed plan. A major rewrite is needed. How is that done; do we flesh it out in the talk page or what? Mogsie (talk) 21:38, 4 May 2013 (UTC) (or perhaps by drafting a page on my user page... hmmm. Mogsie (talk) 21:48, 4 May 2013 (UTC))

I like the plan. Be bold and go for it. Pasado (talk) 03:39, 30 August 2013 (UTC)

I like this outline. Coming to the article with no idea what REST means, the introduction should have illuminated me, not dicouraged. http://searchsoa.techtarget.com/definition/REST has a good definition in plain English ~~

Constraints

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

Inconsistent

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

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

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

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

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

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

Example REST URIs

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)

1. http://stackoverflow.com/questions/1164154/is-that-rest-api-really-rpc-roy-fielding-seems-to-think-so
   • GET /foos/{id} # read a Foo
   • POST /foos/{id} # create a Foo
   • PUT /foos/{id} # update a Foo
2. http://thereisnorightway.blogspot.com/2012/05/api-example-using-rest.html

   Response:

   HTTP/1.1 201 Created

   Location: /api/carts/323392

3. http://blog.2partsmagic.com/restful-uri-design/

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

4. http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http
   • /posts/1
   • GET /transactions/1 HTTP/1.1
5. http://www.slideshare.net/Wombert/designing-http-interfaces-and-restful-web-services-sfliveparis2012-20120608 (Slide 57)
   • http://www.acme.com/products/
   • http://www.acme.com/products/1234

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

Adding more URI examples

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)

New references

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)

• http://www.infoq.com/articles/rest-introduction
• Rest in Practice: Hypermedia and Systems Architecture, By Jim Webber, Savas Parastatidis, Ian Robinson
• RESTful Web Services Cookbook, By Subbu Allamaraju (O'Reilly)
• RESTful Web Services, By Leonard Richardson, Sam Ruby (O'Reilly)
• REST API Design Rulebook, By Mark Masse (O'Reilly)
• SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST, By Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian, Herbj¿rn Wilhelmsen, David Booth (not yet released)
• RESTful Web APIs, by Leonard Richardson, Mike Amundsen w/ Forward by Sam Ruby (O'Reilly)
• Building Hypermedia APIs with HTML5 and Node by Mike Amundsen with Forward by Leonard Richardson (O'Reilly) — Preceding unsigned comment added by Mamund (talk • contribs) 04:10, 16 September 2014 (UTC)

Layman's summary

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)

Largest known implementation

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 89.215.196.162 (talk) 14:55, 9 March 2015 (UTC)

CICS

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

I dearly hope that your question was a mistake and that you realize REST is most definitely not a protocol, but an architecture. There's a huge gaping difference there. —Preceding unsigned comment added by 24.62.204.142 (talk) 12:38, 14 December 2009 (UTC)

Okay, I'll rephrase the question: Does the client/server architecture of CICS qualify as a REST architecture? It seems to meet the important points in the Constraints section. — Loadmaster (talk) 21:48, 7 January 2010 (UTC)

I second the question: my recollection of 3270 terminal-based systems from the 80's (and still in use at places like Costco and IKEA) definitely feels like web clients over HTTP today. Toybuilder (talk) 06:19, 26 April 2010 (UTC)

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)

Split proposal

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 193.194.132.70 (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. 208.81.212.222 (talk) 22:04, 23 April 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Contradiction in Introduction

'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 (talk • contribs) 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)

Proposed merge with Overview of RESTful API Description Languages

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)

• AfDed it. Andy Dingley (talk) 16:32, 17 August 2015 (UTC)

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

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.

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."

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)

References

What is a "coordinated set of constraints"?

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

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:

• Corrected formatting/usage for http://tech.groups.yahoo.com/group/rest-discuss/message/6757

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 II}_{Talk to my owner:Online} 20:56, 31 March 2016 (UTC)

'Technical' tag

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

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?

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)

Just a load of buzzwords.

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

obvious troll is obvious. please try making a point next time, douchebag —Preceding unsigned comment added by 213.133.206.240 (talk) 18:31, 17 May 2010 (UTC)

Please point out which items are buzzwords? Much of the content is a summarization of Fielding's dissertation, not the most buzz-wordy type of document. jsled (talk) 18:28, 17 May 2010 (UTC)

Has it come to anyone that Fielding's dissertation may be pointless and be full of buzzwords as well? :) Not for trolling sake, but clarity of the term. Article is about nothing. It does not define the term, does not explain mechanics of Representational State Transfer and to my opinion represents sad state of academic science. 216.38.138.34 (talk) 00:11, 7 October 2010 (UTC)

That may be the case ['Fielding's dissertation may be pointless and be full of buzzwords'], but we would need serious academic sources that say so before we could act on it in the article. Do you have any refs that point us to more academic descriptions of REST, or denounce it as nonsense for good reasons, or explain it sans the buzzwords (and without commercial hype)? I'd be glad to help incorporate their findings into the article. Please list them here. --Nigelj (talk) 11:13, 7 October 2010 (UTC)

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

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

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

Still agree. The original comment was two years ago. The article is still incredibly difficult to understand. I have two to three years of university-level computer science education and have worked in the field (though not Web sites) for a decade. 86.182.223.14 (talk) 00:03, 26 July 2012 (UTC)

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

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

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

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

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... 185.110.110.45 (talk) 12:58, 14 November 2017 (UTC)

This article doesn't specify cacheable attribute

This article fails to specify which HTTP methods are usually cached by browsers, web servers, and other agents, and which are not. This is pretty important and basic information and should be clearly shown. I know that GET is usually cached by both browsers and web servers; I know that POST is usually not cached by either, but I have no idea for the other methods. A quick glance through this article should have answered that question. David Spector (talk) 21:52, 8 August 2020 (UTC)

HTTP 200 or 404 on bad requests

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

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

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

I don't agree with designing APIs to return 404 when they detect any kind of error. 404 implies that a file (or data) does not exist, that is, that the API is not located at this URL, not that the name of a planet was spelled incorrectly. A more specific error code should be used or invented, such as 801 for "argument is invalid". The only time that 404 should be returned for a valid URL is when a request is being denied for a security violation and specific error information needs to be hidden from the requesting agent, who is presumed to be malicious. Just my opinion. David Spector (talk) 22:02, 8 August 2020 (UTC)

Provide examples for both collection and member resource URIs

Revision 988875340 removed examples relating to member resource URIs from the table in Semantics of HTTP methods. The informational value of having examples for both collection and member resource URIs (as the table did prior to the noted revision) justifies the re-addition of such examples to the table. 96.244.40.214 (talk) 14:34, 12 December 2020 (UTC)

Capitalization

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

No, that's not the spelling in use. 2A00:23C5:FE0C:2100:D74:7CAF:3D41:2C85 (talk) 10:25, 25 December 2020 (UTC)