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 _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
