Subject: [alto] Take 2: ALTO protocol - REST-ful Vs REST-like

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Mar 2011 20:51:53 +0000

Colleagues,

In my original e-mail dated 15th March where I expressed my opinion in response to Enrico's original question of "should [ALTO] follow a strict REST-ful approach or a simpler REST-like one." I attempted to highlight some of the deficiencies in the current specification which I believe would be overcome if the WG took a RESTful approach to the protocol design.

After giving the issue some thought this evening I realised that rather than helping to stimulate a discussion around Enrico's question I probably just succeeded in leading the discussion along a tangent and that what Enrico may have been asking was probably for slightly more abstract discussion of RESTful Vs RESTlike approaches.

Therefore in order to get back to answering Enrico's question I have tried to outline below the advantages I see that taking a RESTful approach would provide over the existing protocol specification without getting into specific protocol details. Most are a repeat of things I have said in other e-mails but I think re-stating them in a separate dedicated e-mail is probably worthwhile.

Therefore, the advantages of taking a RESTful approach to ALTO are IMO:

- Obtainment of a service discovery mechanism as URI discovery is a key feature of a RESTful design.

- Reduced coupling between clients and servers makes interoperability easier because server responses are self-describing.
  + Therefore, client implementation is typically more straightforward as one only needs to understand the data model and not re-learn and potentially re-implement the underlying transport/protocol semantics.
  + More freedom and flexibility is offered to server implementers for how they wish to structure and offer their ALTO service.

- Reduced complexity because it tends to drive focus towards the data itself and the required state transitions instead of the underlying transport/application protocol. 
  + Therefore it will often lead to a simpler, more easily extensible API/protocol that is  more 'naturally' structured, which in turns leads to simpler code and easier future proofing and future extensibility.

- More resilient against post-deployment changes as resources are self-describing and so changes to server deployments do not require client-side code changes and because clients are not so tightly coupled to the server implementation.

- Natural scalability as reuse of middleboxes such as proxies and CDNs is guaranteed.

- Natural reuse of existing (and future) technologies for offering resilient HTTP infrastructure without requiring any ALTO specific coupling.

Finally, to re-iterate one point from my original e-mail, I don't think there is much redesign required of the ALTO data types, it is more a case of restructuring the way ALTO defines (and discovers) URIs and extending some of the ALTO data types to carry information that is currently required to be hardcoded into ALTO clients. I would expect that the work necessary to refactor the current specification can be measured in weeks and therefore it should not by itself present a significant delay to progression of the ALTO specification.

Ben

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 22 Mar 2011 17:15:28 -0400

One of the original arguments against URI discovery (as present in v03 of
the original draft) was P2P clients that are not interested in having a full
HTTP client built-in can perform a simple GET request and download a file.
There is no need for the URI discovery phase.

As far as the 'compromise' approach, I still do not follow the issue of
'interoperability'.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Mar 2011 22:45:28 +0000

> There is no need for the URI discovery phase.

I think you may mean "not interested in having a full ALTO client built-in", right? URI discovery doesn't affect what HTTP features a client needs to support but it would be an extra step and would require ALTO clients to first obtain the "Service Resource" from a well-known URI, process its contents and then execute a GET to the appropriate URI for the service they are interested in.

If the burden of implementing logic to process a JSON object containing a list of URIs (along with their relationship and media type to describe the service they refer to) as well as logic to process a JOSN object containing an ALTO map is considered too high, or that needing to do so is likely to cause the primary target audience to not implement ALTO then avoiding URI discovery would be a strong motivation.

I personally don't think that the additional burden of URI discovery is very high at all but I'm not in the P2P client business.

> As far as the 'compromise' approach, I still do not follow the issue of

Section 10.6 of alto-protocol-07 states:

   1.  Keep the ALTO Protocol as it is;

   2.  Restructure this document to allow a REST-ful protocol as an
       extension, while keeping the protocol unchanged;

   3.  Restructure the protocol.

Assuming Option (2) above is the "compromise" approach then in order to build a RESTful protocol for ALTO it may be necessary to change some of the existing data types. That may result in effectively forking the protocol into two: one version using the current data type format and one using the RESTful data type format. You then have the usual interoperability issues when two versions of the same protocol exist and may be expected to exist alongside one another. That might be considered an issue or might be considered "business as usual" depending on your perspective.

Ben

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 23 Mar 2011 06:52:18 +0800

On 2011-03-23 at 08:15:28, Reinaldo Penno wrote:
> One of the original arguments against URI discovery (as present in v03 
> of the original draft) was P2P clients that are not interested in 
> having a full HTTP client built-in can perform a simple GET request 
> and download a file.

How does the client know which URI to GET?

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 23 Mar 2011 00:18:37 -0400

Server Discovery was discussed in great details in the beginning of the WG.

The result is this draft:

http://tools.ietf.org/html/draft-kiesel-alto-3pdisc-05

Bittorrent can make use of this method

http://www.bittorrent.org/beps/bep_0022.html

The 'first' server discovery problem exists  whether that is the server from
which you will get the cost map or the service discovery server.

You might think I'm against RESTful but I was the one that proposed service
discovery in the first place and worked on it with Alimi in the first
versions of the draft. I'm just reminding the list that:

In two different IETF meetings the consensus was that the protocol could be
very extensible and have many options as long as there was a simple mode of
operation that P2P clients could make use to start working almost 'out of
the box'. This mode of operation was demonstrated in more than one ISP.

Thanks,

Reinaldo