26.Sep.2009 at 20:36 by Oleg Baranovsky
Great presentation, one of the most concise intro to design patterns in 60 minutes I've ever heard.
Web Service Design with AtomPub
Ben Ramsey (25.Sep.2009)
Talk at CodeWorks 2009 (Los Angeles) (English - US)
The Web is transforming into a platform for distributed applications where rich clients connect to web services to retrieve and store data, but these services need a common language. The Atom Publishing Protocol provides is one such language. Since 2003, the Atom format has been used as yet another feed format like RSS, but the Atom protocol opens the door to far more uses of Atom as both a means for distribution and publication. Ben Ramsey introduces the Atom format and protocol, explaining how these can form the foundation of any service for publication and distribution of content.
Quicklink: https://joind.in/680
Who are you?
By clicking this button you are declaring that you are the speaker responsible for it and a claim request will be sent to the administrator of the event.
If the claim is approved you will be able to edit the information for this talk.
Are you sure?
Comments
26.Sep.2009 at 20:40 by Oleg Baranovsky
Ben did a great job describing the intricacies of implementing AtomPub with great examples. This presentation can also serve as a great intro to REST and building the RESTful service in general.
26.Sep.2009 at 20:55 by Oleg Baranovsky
sorry posting my comments in few windows simultaneously, so obviously mixed them up, please disregard my comment on design patterns.
25.Sep.2009 at 16:49 by Joe Devon
Regarding the POST vs. PUT question asked, can PUT be used to create a resource if it doesn't exist...some references:
Quoting: http://atomenabled.org/developers/protocol/atom-protocol-spec.php#edit-via-PUT
"To edit a Member Resource, a client sends a PUT request to its Member URI, as specified in [RFC2616]."
Quoting: http://tools.ietf.org/html/rfc2616#page-55
"9.6 PUT
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request."