Hello You can already do REST over XMPP using XEP-0332 (HTTP over XMPP), as mentioned in the proposal: http://xmpp.org/extensions/xep-0332.html
This extension is used in UPnP+ architecture documents, where they extend UPnP to XMPP, extending the reach of billions of devices to XMPP. The arguments mentioned for not using XEP-0332 are the following: 1.services are discoverable and explorable, 2.asynchronous invocation can be performed in parallel, 3.generation of clients on the fly based on the capabilities of resources, and 4.multiple input and output types definitions are possible. Regarding (1): Services are discoverable and explorable even using HTTP over XMPP. One such method is CoRE, that is also used in CoAP, and is standardized by IETF. Another is WADL, as is mentioned by the REST over XMPP proposal. Other proprietary methods are also available. https://datatracker.ietf.org/wg/core/charter/ http://www.w3.org/Submission/wadl/ Regarding (2): This can be done using HTTP over XMPP as well. (Nothing prohibits you from doing it, except a "gentlemen's agreement" in the original HTTP specification, something that is not even kept in modern HTTP solutions.) Regarding (3): What does "generation of clients on the fly" mean? If it means what I think it means, there's nothing that prohibits you from doing this with XEP-0332. Regarding (4): There are multiple ways to define multiple resources in HTTP, both for input and output as well. Instead, it seems that this is the true argument: "... but requires an implementation of both protocols: XMPP and HTTP". Well, the alternative seems to require both XMPP and "REST over XMPP". And if you define a "REST interface" (which presupposes a HTTP, or CoAP-like interface), would it be a stretch? Also, using "REST over XMPP", you have the following problem: Say you actually create a REST over XMPP API. There are two possibilities: a) Either the API is for proprietary use, i.e. no interoperability is intended. Why then not create a proprietary interface instead of creating an abstraction that implies additional complexity in the implementation stage? b) Or the API is for use by third parties in an interoperable setting. But those parties, who wants to consume REST APIs, are both familiar with HTTP (or CoAP)-based REST-APIs, and have that implemented. Why should they have to implement yet another extension? Another benefit of using XEP-0332, is that resources can be linked to using URLs (using the httpx uri scheme), which allows for embedding micro formats, meta data, links, etc., into REST responses, something that is very common today. Best regards, Peter Waher -----Ursprungligt meddelande----- Från: XMPP Extensions Editor [mailto:edi...@xmpp.org] Skickat: den 11 maj 2015 15:22 Till: standards@xmpp.org Ämne: [Standards] Proposed XMPP Extension: REST with XMPP The XMPP Extensions Editor has received a proposal for a new XEP. Title: REST with XMPP Abstract: This specification defines how the Representational State Transfer (REST) architectural style can be applied to an XMPP overlay network. It specifies an XMPP protocol extension for accessing resources and transporting resource metadata and XML-REST encoded requests and responses between two XMPP entities. URL: http://xmpp.org/extensions/inbox/rest.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
