Case Study: RESTful Web Services at Orbitz
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Alex joined Orbitz LLC in 2004 and is responsible for providing technical leadership and guidance in the development of foundational technologies, core libraries and APIs for the enterprise-wide use, as well as establishing and maintaining common design principles and standards used within the company and integration of new software development practices within the development community.
SpringOne 2GX is an annual event; it includes a technical exploration of the Spring ecosystem along with the latest developments in the Groovy/Grails space. As a participant, you will have the opportunity to attend two great events at one venue. Whether you're a Spring enthusiast, Tomcat user, Groovy/Grails fan, or just interested in open source development, you'll find valuable content in sessions presented here.
:)
by
Jules Jacobs
Source code URL?
by
Bryan Ross
RE: Case Study: RESTful Web Services at Orbitz
by
Nick Hrycan
Good job
by
Mark Wutka
Very nice
by
Faisal Waris
Not really REST though. Fielding's thesis is mentioned but with a take-it-with-a-grain-of-salt caveat. However Fielding's the one that defines REST! Lets just call it an SOA.
Still too much plumbing code seems to be required. My exprience with WSDL based services seems a lot simpler programming wise - the entire plumbing code can be generated by tooling from metadata. Protocol Buffers define the data format only - the service interface is not part of it.
Protocol Buffers' speed and versioning is impressive.
Doing versioning with XML schema is an acquired skill - it does not come naturally.
I wonder if Protocol Buffers will work well where a large complex and complex vocabulary needs to be developed/used as in a large enterprise - I could not find any references to name scopes (namespaces).
nice decisions and versioning
by
Guilherme Silveira
Just a small question on versioning: the example shows how compatibility issues are handled when a new field is added. What is the usual approach to information removal: changing what a client expected to receive. How would clients behave if I simply remove the field from the description? How could it cope with it? Any suggestions?
Its a really nice presentation, because it focuses on why and how.
Regards
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think