Hi Ben, On Tue, Mar 22, 2011 at 5:00 AM, Ben Niven-Jenkins <b...@niven-jenkins.co.uk> wrote: > Richard, > > On 22 Mar 2011, at 07:38, Richard Alimi wrote: >> On Tue, Mar 15, 2011 at 10:14 AM, Ben Niven-Jenkins >>> BTW When I say "redesign" I don't think there is much redesign required of >>> your data types, it is more a case of restructuring the way you define (and >>> discover) URIs and extending some of your data types to carry information >>> that currently you require to be hardcoded into ALTO clients. >>> >> >> Agreed. We had consciously tried to keep the messages self-contained, >> and I think the major items that are up for debate are exactly the two >> items you pointed out below. >> >> Note that this is more-or-less where a 'compromise' approach came in. >> To expand a bit further on what we wrote in the discussion section >> 10.6 of the -07 draft, one possibility was to separate the draft in >> terms of structure, but not change the semantics, such that the data >> structures and message encodings were separate from the rest. If done >> right, that could make it easier to design a REST-ful extension to the >> protocol. >> >> That said, I do personally feel somewhat hesitant to take a >> middle-of-the-road approach. If we can settle on the "right" way to go >> now, then it seems reasonable to just put in the 2-week effort to make >> a significant update to the draft. That would present less >> opportunity for divergent implementations down the line. >> > > I don't like the "compromise" approach. It would actually lead to divergence > IMO because then you have the issue of implementation A implementing ALTO > over the "REST-like" specification and implementation B following the > REST-ful extensions and how to interoperate them. You actually cause more > work and risk more pain in the end. >
Agreed. > >>> Regardless of the definition of RESTful which can sometimes end up in a >>> philosophical debate around semantics, below I have listed some downsides >>> to the approach currently taken that occurred to me from a first reading of >>> the draft: >>> >>> The current draft re-specifies or prescribes behaviour for particular >>> sub-features of HTTP. Without extensive analysis and comparison (which I >>> have not done) it is not easy to tell whether the "profile" specified in >>> the draft is compatible with HTTP/1.1 or contradicts RFC2616 in some way. >>> This places an unnecessary burden on implementers to do such analysis and >>> presents the risk that implementers may not be able to use standard HTTP >>> library code to implement ALTO clients and servers and therefore may negate >>> the obvious benefits of being able to reuse standard library code to >>> implement the underlying HTTP transport. Furthermore it risks causing >>> additional interoperability issues as it opens up the potential for >>> ambiguity of interpretation on how to implement the ALTO "profile" of HTTP >>> rather than letting implementers (and the ALTO WG) concentrate on the data >>> types and services you wish to carry over HTTP. Compatibility with existing >>> HTTP infrastructure including proxies, cache >>> s and CDNs is also increased. >>> >> >> While this might be a reasonable concern, I'm wondering if this is >> actually a problem. I believe the contents of the draft are all >> fairly standard uses of HTTP, and it was drawn from implementation >> experience as well. > > Let's put my example of re-using a HTTP library to one side. > > One of the primary purposes of RFCs IMO is to specify the necessary protocol > details to enable someone who was not involved in the initial design > decisions to implement the protocol. By re-specifying or prescribing HTTP > sub-features you make the job of that person wishing to implement ALTO more > difficult. If you just said "ALTO operates over HTTP" then an ALTO > implementer knows they have to implement HTTP. As it stands an ALTO > implementer does not know whether you are reusing HTTP as-is or whether you > have changed the semantics of HTTP in some subtle way and therefore an ALTO > implementer needs to do additional work to determine what the changes may be > that is unnecessary if your claim that ALTO uses "standard HTTP" is correct. > > You and others who have been involved in ALTO since the beginning may know > that what you have specified just reuses HTTP but it is not clear to someone > reading the specification for the first time with no prior involvement in > ALTO that that is the case. > > >> Given that there are more than a few groups with >> implementations, if people needed to hack HTTP library implementations >> to get it to work, I'm sure we would have heard about it. :) That >> said, if there actually are issues that cause anyone to touch a line >> of an existing, reasonable HTTP client or server library to implement >> this, please let us know, and it should be fixed. > > This misses the point, IMO. Either ALTO reuses standard HTTP and therefore > all the ALTO specification needs to say is that the ALTO data formats are > carried over HTTP as specified in RFC2616 or ALTO does not use standard HTTP > in which case it should clearly state that it does not operate over HTTP and > that it is a new protocol based on HTTP but that the new protocol is > divergent and the ALTO specification should state precisely what those > divergences are. > > If ALTO is just reusing HTTP and while working on ALTO things come to light > in the HTTP specification that require clarification then the HTTPbis WG is > already chartered to do that work. > >> Apologies for drawing that distinction, but I think it would be good >> to keep this thread to the technical merits of REST-like vs. REST-ful >> as opposed to problems with the existing draft that may not actually >> be there. >> > > The distinction is useful. If ALTO was RESTful we wouldn't need this > discussion because none of the ambiguity from the current specification > trying to profile HTTP would exist :-) Maybe I am misunderstanding here. I think the existing draft makes extremely basic usage of HTTP, in that it uses GET, POST, headers (and in one case, trailers). If you mean by profiling HTTP that we are using only a subset of the features, then yes, thats true (and I think it would be true of quite a few protocols out there). However, if you mean that we are using HTTP in a non-standard way, then I think I disagree. That said, it is certainly true that we could use more of the features, e.g. content negotiation, within ALTO to accomplish what we need. In short, my understanding of the debate here is about how we use the feature set of HTTP, as opposed to whether we use "standard HTTP" or not. Thus, I don't understand this statement: "Either ALTO reuses standard HTTP and therefore all the ALTO specification needs to say is that the ALTO data formats are carried over HTTP as specified in RFC2616 or ALTO does not use standard HTTP ..." In the former case, doesn't that leave it extremely underspecified? We'd still need to state how the link document is created/formatted, how content negotiation and MIME types are employed, etc. Right? > In terms of technical merits of RESTful, there are plenty of resources on the > Internet discussing RESTful design and its merits along with examples of how > refactoring applications to a RESTful design has lead to reduced code > complexity, but I would state some of the primary motivators for me would be: > > - Reduced coupling between client & server 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. > - Reduced complexity as URIs actually tend to be simpler and more 'naturally' > structured, which in turns leads to simpler code and easier 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. > - Scalability as reuse of middleboxes such as proxies and CDNs is guaranteed. I think that is a great list to serve as input to the discussion (though we have already taken care to accomplish the first item for other purposes - wished to allow redistribution amongst ALTO clients). I'd be interested to hear how others feel about these benefits as well. > >>> The draft combines the use of POSTs with Request bodies and querystrings. >>> While not in contravention of RFC2616 it is pretty horrible and ugly IMO. >>> You could achieve the same result by encoding the querystring in the >>> Request body or by performing a GET (or if the Request is not idempotent a >>> POST, although personally I don't like POSTs with querystrings) with a >>> query string. >>> >> >> Just to be clear, is this a point about elegance or are there >> technical aspects that cause it to fail (e.g., existing library >> implementations that don't handle it properly)? > > Using querystrings and Request bodies to pass data *at the same time* is > inelegant but also a very bad design IMO. Pick one or the other but don't try > and use both at the same time. > >> Either is response fine, I would just like to be sure on this thread >> that we understand the technical tradeoffs at stake. That seems to be >> orthogonal to the REST-ful vs. REST-like question, since the existing >> draft could easily change whether parameters are specified in the body >> or query-string. > > IMO one of the fringe benefits of RESTful design is that it tends to > naturally lead to more elegant design which in general makes the design > simpler for someone to "pick up" and therefore less open to ambiguity. > I personally feel like we should be debating the technical merits above, as opposed to elegance or inelegance. One could make similar arguments about how the fully REST-ful design that we are talking about is harder for someone to pick up, but I don't think that is useful to debate here. The technical merits that you listed above are not subject to that, so it seems more useful to focus on those in this thread. > In terms of tradeoffs, I think the advantage you have sticking as you are is > that you have some early implementations. The disadvantage is as you come to > extend ALTO over time you make (IMO) the job of doing so more cumbersome > because you need to consider more than just the data you have and the > interactions (state transfers) between representation of that data. > Good point. Personally (though I can't speak for other implementers), I would rather get this right initially without feeling "attached" to existing implementations. That said, since the encoding and overall behavior of the protocol don't need to change (though the interactions on the wire would), I don't think that existing implementations would need to change all that much. > The advantage of a RESTful approach is you can spend your time only worrying > about the data & its interactions, which at the end of the day is primary > motivation for the ALTO WG existing and is also the bit of protocols/software > design that's the most interesting/fun/satisfying (IMO). I believe it will be > easier to extend the protocol later and you will ultimately end up with a > much cleaner specification. The disadvantage is that you need to refactor > your specification a bit, but that is not a big deal IMO because it is still > an Internet-Draft so backwards compatibility with an existing RFC is not an > issue. > Agree about getting this right the first time, and I agree about the overall benefit (data vs interactions), though I think your list above elucidates that in a much clearer way that can be discussed on this thread or in the WG session. Thanks, Rich > Ben > > > _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
