Editor: Gottfried Zimmermann
Copyright 2013, OpenURC Alliance


This document looks at the URC-HTTP 2.0 Protocol and to what degree it follows the principles of "Representational state transfer" (REST). A potential action plan for making parts of URC-HTTP 2.0 fully RESTful is presented, and implications are discussed.

Status of this Document

This document is an informal appendix to the OpenURC Alliance Technical Report on the URC-HTTP 2.0 Protocol.

Table of Contents

Parts of URC-HTTP

URC-HTTP is more than a protocol for exchanging states of objects. URC-HTTP can be divided into 4 main parts:

  1. Discovery (section UIList)
  2. Out-of-session messages
  3. In-session messages
  4. Update mechanism (section Update Channel)

The REST architectural style assumes that resources are accessed and manipulated by a client by sending HTTP requests to a server. This assumption does not hold true for the discovery part which follows the existing UPnP Remote User Interface specification. It also does not fit for the update mechanism via TCP/IP sockets. This call-back communication mechanism has been deliberately designed to be event-driven and not HTTP-based. There is only one out-of-session message defined in URC-HTTP, and it represents a special case of discovery which does not really fit for the application of REST.

When looking at the RESTfulness of URC-HTTP we will therefore focus on its in-session part which is indeed HTTP-based. In the following, "URC-HTTP" is meant to refer to in-session messages of the URC-HTTP protocol only.

REST Principles and the URC-HTTP Protocol

This section describes the main principles of REST, and to what degree the URC-HTTP protocol follows them.


The separation of concern between client and server is followed in general by URC-HTTP. The state of a socket and its elements is managed by the server, and information on these states is communicated via GET and POST messages.


The session concept of URC-HTTP violates this REST constraint since it requires the server to remember a session, and clients to refer to a previously opened session (Open Session and Close Session requests). This is necessary for targets that maintain different states for different clients ("multi-client ability").


REST requires cacheability for GET responses. Due to the session-bound meaning of URC-HTTP requests, caching is not possible in general. This violates this REST constraint.

Layered System

Intermediary entities may be placed between a client and a server. However, one of the reasons for doing so (shared caching) is not applicable to URC-HTTP (see above constraint "Cacheable").

Uniform Interface

The uniform interface characterizes a typical RESTful protocol, with its four guiding principles.

In URC-HTTP, resources are socket elements whose states are accessed by clients by sending HTTP POST requests to a server, with functions being specified as part of the URI, and resources being identified as message bodies. However, REST indicates the function by the choice of the HTTP method (GET, PUT, POST or DELETE), and to identify the requested resource or collection of resources via the URI. This is different from URC-HTTP.

Another violation of the uniform interface constraint is that in URC-HTTP batch requests for getting socket element states are encouraged by prividing a list of paths. This is done on purpose for better efficiency.

In general, URC-HTTP messages are self-descriptive since the responses are self-contained and are always interpreted by the same client (no MIME type differentiation necessary). However, as an exception, the Get Resources message response in URC-HTTP doesn't repeat the information contained in the pertinent request. It requires the client to remember the resource items requested in the previous query message. This violates REST, but helps to save bytes on network traffic.

In URC-HTTP, socket element paths are communicated via Get Value messages, and can then used to start subsequent requests (following the principle of HATEOAS). However, as described above, references to resources are contained in message bodies rather than in their URIs.


In essence, we can state that URC-HTTP is not RESTful, although it has some similarity with REST and follows some of its constraints and principles. But URC-HTTP clearly deviates from REST in the following points:

However, these deviations are deliberately designed into URC-HTTP for various reasons, in particular session support and network efficiency.

Potential Action Plan

Given the various deviations of URC-HTTP from REST, it require a significant effort to modify URC-HTTP to be completely RESTful. However, this would arguably have some undesired implications, as described in the following table.

NOTE: These actions would only make the in-session message part RESTful. The other parts would remain as they are.

Potential Action Implications on URC-HTTP
Abandon the session concept, in particular:
  • Remove the Open and Close Session requests.
  • Identify sessions as part of the path to a resource (URI).
  • A GET message to the root path of a socket means opening a session. But how to close the session?
Seems feasible, but benefit is cosmetic only since the server and client would still need to remember session identifiers.
Reformat the URC-HTTP messages to code functions as HTTP methods, and paths as URIs. Batch requests are not allowed anymore.

Potential loss of security since Basic HTTP authentication passwords are not encrypted for GET messages.

More delay in building the user interface because multiple values have to be retrieved by multiple Get Value requests.

Add additional information (corresponding query) to the Get Resource response to be self-descriptive. More network load.