Hi, It seems to be a reasonable compromise to remove backward compatibility issues. I also think that the version number mut be defined in the url and not as a query parameter.
So what would be our strategy ? Propose a new endpoint on server side and then upgrade all clients to support this new endpoint ? Best regards, Jérôme 2013/11/6 Adam Franco <afra...@middlebury.edu> > > Current endpoints: > > /validate - CAS 1.0 protocol > > /serviceValidate & /proxyValidate - CAS 2.0 protocol > > > > Proposed endpoints: > > /v3/serviceValidate % /v3/proxyValidate - CAS 3.0 protocol? > > Another +1 for a version protocol-version name-space. Any of /v3/, /3/, > /CAS3/, /CASv3/, /CAS/3/ would be reasonable. The only distinction I can > think of is whether it makes sense add a "CAS" prefix to avoid conflicts > with the server's other potential protocol end-points (SAML, OpenId, etc). > > A protocol-version name-space will also provide an upgrade path for those > of us doing a variety of potentially conflicting things in the CAS 2.0 > response: > 1. We will continue to maintain our custom JSP additions for the coming > months/years. > 2. Encourage clients to use /v3/serviceValidate, et cetera > 3. Once no one is using the CAS 2.0 URLs we can drop support of the JSP > additions and go back to an un-customized installation. > > Best, > Adam > > -- > > Adam Franco > Senior Software Engineer - Web Applications > Library and Information Services > Middlebury College > Middlebury, VT 05753 > afra...@middlebury.edu > 802.443.2244 > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: lel...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
