Seeing as how the new Basecamp API reflects a similar use of RoR that I have been working on I''m curious as to what we can expect to be extracted from there in 0.13? Was the API written as an ActionWebService or just as a set of controllers? Any generic AR xml parsing/output methods that we may see in 0.13? Any reason you decided to do everything with HTTP Get instead of utilizing PUT/DELETE? Overall looks very cool, once again something to strive towards. Josh
On 18/05/2005, at 8:37 AM, Josh Knowles wrote:> Seeing as how the new Basecamp API reflects a similar use of RoR that > I have been working on I''m curious as to what we can expect to be > extracted from there in 0.13?Which Basecamp API is this? - tim lucas
> Which Basecamp API is this?http://backpackit.com/api/ -Caleb
Caleb Buxton wrote:> > Which Basecamp API is this? > > http://backpackit.com/api/ > > -CalebIt was sarcasm (Basecamp != Backpack) I''ve been mixing them up when I talk about them about as much as I do country/company. -Matt> _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >
On May 17, 2005, at 5:37 PM, Josh Knowles wrote:> Was the API written as an ActionWebService or just as a set of > controllers?Looks like they''ve just codified the use of a Rails-esque URL scheme and added support for accepting YAML and XML requests. I''ve not tested this idea, but I think that a REST service can be easily constructed without changing many of the details of constructing a normal Rails app. You would want to make your controller verify that mutator actions use something besides GET and expect XML (or YAML!) in the request body.> Any generic AR xml parsing/output methods that we may see in 0.13?Sounds like xml-simple will be in the next release. I personally am not too fond of how xml-simple decodes the structures in the Backpack API, but its a good start. Munging XPaths and pseudo-DOM in REXML isn''t a whole lot better or worse. A matter of taste, really.> Any reason you decided to do everything with HTTP Get instead of > utilizing PUT/DELETE?Merely for the sake of being pedantic, the Backpack API is all POST (at least the example wrapper is). :) -- ~akk http://therealadam.com
On 5/18/05, Josh Knowles <joshknowles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Was the API written as an ActionWebService or just as a set of controllers?Implementing a REST web service using AWS isn''t possible right now [1]. This is because existing protocols like SOAP and XML-RPC place some restrictions: With SOAP, it should not really be impossible to implement a REST web service, but WSDL doesn''t allow us to specify the target URI per operation when using the SOAP binding, but only a SOAPAction header, which has no effect on which URI the caller sends the request to. When using HTTP binding in WSDL, values are sent as GET or POST parameters. With XML-RPC, the restriction lies mostly on the client side (there are *many* clients out there), in that most of them expect to send all requests to a single endpoint URI. I see SOAP/WSDL''s drawback that they were design-by-committee specifications, implementation complexity is massive, so it feels clumsy to use without lots of supporting tools and frameworks. An example SOAP message: <?xml version="1.0" encoding="utf-8" ?> <env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <env:Body> <n1:doGetCachedPage xmlns:n1="urn:ActionWebService" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <key xsi:type="xsd:string"></key> <url xsi:type="xsd:string"></url> </n1:doGetCachedPage> </env:Body> </env:Envelope> XML-RPC is simple, but the XML messages are rather hard to parse with human eyes, as the elements aren''t self describing. An example XML-RPC message: <?xml version="1.0" ?> <methodCall> <methodName>myns.methodName</methodName> <params> <param> <value> <int>41</int> </value> </param> </params> </methodCall> SOAP/WSDL has the general tools support in that you as developer aren''t going to need to do much to get a working client going, and if you''re lazy, the WSDL can be your "API specification" document, at the expense of needing a layer insulating you from the messages coming in, as you really don''t want to be writing a spec-compliant protocol implementation yourself. It also means living with the warts and all, and not having freedom of implementation. The Backpack API is rather clean from an implementation and human readable perspective, but you''re always going to have to write the API specification yourself (difficult to see how you''re going to extract it from the implementation), and get it right. [1] The REST approach really rocks though, I''m going to try and find a way to make that feasible using AWS. Need to find a nice way to decode Backpack-style XML messages into meaningful method parameters. Regards Leon
> With SOAP, it should not really be impossible to implement a REST web > service, but WSDL doesn''t allow us to specify the target URI per > operation when using the SOAP binding, but only a SOAPAction header, > which has no effect on which URI the caller sends the request to. When > using HTTP binding in WSDL, values are sent as GET or POST parameters.I don''t know much at all about WSDL, beyond getting Visual Studio.Net to generate web service proxies for me. However, Joe Gregorio wrote an Atom API WSDL a while back. http://www.atomenabled.org/developers/api/ Couldn''t other REST services use similar WSDLs? -- rick http://techno-weenie.net
On 5/21/05, Rick Olson <technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I don''t know much at all about WSDL, beyond getting Visual Studio.Net > to generate web service proxies for me. However, Joe Gregorio wrote > an Atom API WSDL a while back. > > http://www.atomenabled.org/developers/api/ > > Couldn''t other REST services use similar WSDLs?I''d love to be proven wrong, but that WSDL does not describe a REST service. It describes what appears to be a fairly generic server-side dispatcher (being limited by WSDL and all). Just describing operations (RPC methods) named "PUT" and "GET" and "POST", but still using actual HTTP POST to a single URI (http://SERVER/AtomApi.aspx) for all requests is not what I''d call REST :) I prefer the Backpack API approach of sending the request operating on a resource to the distinct URI for that resource instead. I''d also use the actual HTTP methods to perform the requests instead of faux-methods :) Leon