Bill Moseley <[EMAIL PROTECTED]> wrote on 07/28/2008 01:53:11 AM: > On Sun, Jul 27, 2008 at 06:42:23PM -0500, [EMAIL PROTECTED] wrote: > > > widget.1.get > > > widget.2.get > > > etc. > > > > > Icky, I think the API should be versioned -- not methods. What if > > the methods across versions are not compatible (widget1 output used with > > foo2) versioning the api forces all methods to be used with their tested > > and versioned partners. When you have 30 or 40 different revisions and > > developers start relying on mismatching methods from different versions > > that seems like a headache waiting to happen. > > I completely agree. > > I suppose a "version" XMLRPC parameter in the request payload is > possible, but I'm actually leaning more toward just using separate > endpoints: > > http://localhost:3000/rpc1.2 > http://localhost:3000/rpc1.3 > > or > > http://localhost:3000/rpc/1.2 > http://localhost:3000/rpc/1.3 > > or > > http://localhost:3000/rpc?version=1.2 >
I guess there would be nothing wrong with: api10.example.com:3000/method api11.example.com:3000/method either, I guess it depends on if users are going to be using it or if it is all app usage. if all app usage that would allow you to just rev the api in source control / separate procs and not have a mammoth app with x number of api versions hanging out and possibly conflicting. _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
