Your SlideShare is downloading. ×
Rest Vs Soap Yawn2289
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rest Vs Soap Yawn2289

1,866

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,866
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ReST vs SOA(P) yawn ... Instead ... Facts and confused metaphors for Understanding ReST
  • 2. Early Web • Human edited Files / Document Oriented programatic output • A patchy server opening up access to static files • Massive Upgrade to Human Knowlege, Communication, and Transparency
  • 3. Tech Progress • CGI Scripts • Screen scrapping clients • Spiders, Robots, and Internet Duct-tape • Dynamic HTML • XHTML & XML formats • CSS
  • 4. Roy T. Fielding Architectural Styles and the Design of Network-based Software Architectures http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm by Paul Downey
  • 5. ReST is not • A technology • A set of standards • COTS software • A tooth paste http://www.lostwackys.com/Wacky-Packages/die-cuts/Crust.htm
  • 6. ReST is • A series of constraints that defines a specific flavor of system architecture • Layered • Client / Server Representational e • Code on Demand State • Client Cache Transfer • Stateless Server
  • 7. ReST is Weak Poor network latency Difficult to identify authoritative response Uniform Interfaces degrade performance Lacks “mandatory extensions” - must understand Optimized for course grained transmissions Hard to customize
  • 8. but also ReST is Dope because of Low technical barrier to play General Interfaces Resource Extensibility Massively Scalable Independent Deployment
  • 9. UnReST Lastly in his Thesis Fielding identifies these issues with HTTP • Cookies - enabled server side session • Personalization • Vendor specific extensions Did the masses listen to academia?
  • 10. A Common Path /Server.do?some=stuff RPC style Sessions XML-RPC Large Controllers SOAP Query String Param mappers Form deserializers Abstract away the network!
  • 11. A Common Path? • Focus on APIs, distributed transactions, etc • Procedural code • Distributed OOP 1992 called, it wants it’s CORBA back ...
  • 12. http://www.wisconsinhistory.org/whi/fullimage.asp?id=13487 RPC usually fights the web with Complexity ReST Web Services are injected into HTTP molds with gooey Web2.0 filling
  • 13. ReSTful Web Services? Madge! You’re suggesting there’s issues with transporting all my SOAP traffic over POST through one URI? Relax, SOAP document literal over HTTP is the most popular. But won’t I lose transport independence? Yes, but if you add using GET, more endpoints, etc you can have caching for free! via Shannon C. on Flickr
  • 14. ReST in 90 seconds • URIs • Resources • Representations • State Transitions • User agents, intermediaries, and servers • Uniform Interfaces
  • 15. Core Concepts http://flickr.com/photos/68661927@N00/350737025/in/photostream/
  • 16. URI • Everything has a name • Excel good C3 = B3 * B2 • Outlook bad - No address for “Last email from RSDG” • This presentation is available at http://www.slideshare.net/ozten/slideshows
  • 17. Resources • Any “Thing” - concept, event, person • Anything you would want to point too • Request or Respose = data + metadata in an envelope with control data • Explicit request / response - no hidden state • Easier to load balance • Easier to troubleshoot
  • 18. Representations • A serializable description of a Resource • Modify resources through representations • XHTML Microformats • Industry standard binary formats ( jpg, mpg, etc ) • JSON • XML ( Atom or custom ) • The resource itself for static files
  • 19. State Transitions Hypermedia as the engine of • Links application state • link, img, and a tags • Forms Links and forms are the hypermedia elements of XHTML. They create the network effect of the web. Every resource represents a state in your application. State transition aren’t hidden behind an API, but are instead transmitted back in forth in a hypermedia protocol. Client’s can follow these links and be less fragile to future changes. RPC usually lacks links and encourages assumptions about formatting URI or server states.
  • 20. Client / Server • User Agents • Web browsers • HTTP libraries - libwww, libcurl, etc • Proxies • Gateways • Servers
  • 21. Uniform Interfaces HTTP Method Guarantee # Of Effects GET, HEAD Safe 0 PUT, DELETE Idempotent 1 POST None ??? Möbius strip via wikipediajpg
  • 22. So What? Most popular example: • Stateless Client / Server rules give us • Client Side Cache • HTTP 1.1 conditional GET • Implement Etags, If-Modified-Since • Real savings time, $, and complexity
  • 23. Common Misconceptions
  • 24. But, Browsers only do GET and POST • Yep, their horrible ReST clients • Web Developers use XMLHttpRequest for PUT, DELETE, etc • Outside of browser, use HttpClient, libwww, or libcurl • ReST uniform interface means you can tunnel PUT, DELETE over POST or write one off Proxy via cleansweepsupply.com
  • 25. ReST is just CRUD • Sure you can expose HTTP POST SQL INSERT CRUD Create DB on web GET SELECT Read • Too cute and simple PUT UPDATE Update right? DELETE DELETE Delete It’s about favoring protocols Refactor design to use and resources over APIs. new resources if you run out of HTTP methods
  • 26. Example Requirment: A user can subscribe to an artist feed ArtistWS.subscribeUserTo( User user, Feed feed ) POST /subscriptions OR artist=Art.1234 feed=Feed.2345 email=false Location: http://foo.com/subscription/Sub.3456 Artist - GET, PUT, DELETE Feed - GET, PUT, DELETE Subscription - GET, POST, PUT, DELETE User - GET, POST, PUT, DELETE
  • 27. We need WSDL for ReST • Yes, programmers need documentation and a way to discover functionality • ReST gets for free • Uniform Interface • Transparent data and HTTP tools • Explicit state transitions • Power of XML - XSD, extensibility, etc
  • 28. • WSDL tries to hide network, parsing and formating messages, loose typing • Often WSDL is an afterthought, a verbose format itself, used to generate incredibly verbose SOAP payloads - Yeah tools! • Doesn’t actually solve the really hard problems, still need other WS-* specs focused on such as transitions or security
  • 29. • ReST still requires you to document your resources, representations, and other highly application specific details • URI, Microformats, XSD, hypermedia, etc let ReST clients do this in a lightweight manner • URITemplates, XHTML 5, etc coming • besides, WSDL2Foo is bad
  • 30. WADL • Don’t agree that WSDL2Foo is bad? • OKAY, Use WADL • WSDL like tool
  • 31. Rare Conceptions • ReST is nothing more than the web circa 2003 • Human and programatic web both thrive under ReST constraints • It’s the Data, not the Source, not the API, not the platform • Mashups and ??? (future emergent techniques) are easier with ReST
  • 32. Surprise, you’re soaking in it... Everything we do over HTTP is “ReST”, but we can build systems that work with the natural form Call the police! These of the web APIs are a crime!
  • 33. ReST isn’t your solution • If your doing sophisticated mission critical distributed programming with transactions across multiple partners in synergistic fashion • Use CORBA, EDI, Stateful protocol, etc • Client and server written in Java? Use RMI, Jini, etc • Invent a new architecture by applying constraints to derive a solution that works with your problem space ala Chapter 5 of Fielding
  • 34. Resources •http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm •http://rest.blueoxen.net/ •http://microapps.org/ •http://bitworking.org/news/ •http://intertwingly.net/blog/ •http://www.tbray.org/ongoing/

×