ReST Vs SOA(P) ... Yawn
description
Transcript of ReST Vs SOA(P) ... Yawn
ReST vs SOA(P)yawn ...
Instead ... Facts and confused metaphors
for Understanding ReST
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
• CGI Scripts
• Screen scrapping clients
• Spiders, Robots, and Internet Duct-tape
• Dynamic HTML
• XHTML & XML formats
• CSS
Tech Progress
Roy T. Fielding
Architectural Styles and the Design of Network-based Software Architectures
by Paul Downey
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
ReST is not
• A technology
• A set of standards
• COTS software
• A tooth paste
http://www.lostwackys.com/Wacky-Packages/die-cuts/Crust.htm
ReST is• A series of constraints that defines a
specific flavor of system architecture
• Layered
• Client / Server
• Code on Demand
• Client Cache
• Stateless Server
RepresentationaleStateTransfer
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
ReST is Dope
Low technical barrier to play
General Interfaces
Resource Extensibility
Massively Scalable
Independent Deployment
but also
because of
UnReST
• Cookies - enabled server side session
• Personalization
• Vendor specific extensions
Lastly in his Thesis Fielding identifies these issues with HTTP
Did the masses listen to academia?
A Common Path
SOAP
/Server.do?some=stuff
RPC style
Large ControllersQuery String Param mappers
Form deserializers
Sessions
XML-RPC
Abstract away the network!
A Common Path?• Focus on APIs, distributed transactions, etc
• Procedural code
• Distributed OOP1992 called, it wants it’s
CORBA back ...
ReST Web Services are injectedinto HTTP molds
with gooey Web2.0 filling
RPC usually
http://www.wisconsinhistory.org/whi/fullimage.asp?id=13487
fights the webwith Complexity
ReSTful Web Services?
via Shannon C. on Flickr
Madge!You’re suggesting there’s issues with transporting all my SOAP traffic over POST through one URI?
But won’t I lose transport independence?
Relax, SOAP document literal over HTTP is the most popular.
Yes, but if you add using GET, more endpoints, etc you can have caching for free!
ReST in 90 seconds
• URIs
• Resources
• Representations
• State Transitions
• User agents, intermediaries, and servers
• Uniform Interfaces
Core Concepts
http://flickr.com/photos/68661927@N00/350737025/in/photostream/
URI• Everything has a name
• Excel good C3 = B3 * B2
• Outlook bad - No address for “Last email from RSDG”
• This presentation is available athttp://www.slideshare.net/ozten/slideshows
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
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
State Transitions• Links
• link, img, and a tags
• FormsLinks 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.
Hypermedia as the engine of application state
Client / Server
• User Agents
• Web browsers
• HTTP libraries - libwww, libcurl, etc
• Proxies
• Gateways
• Servers
Uniform InterfacesHTTP Method Guarantee # Of Effects
GET, HEAD Safe 0
PUT, DELETE Idempotent 1
POST None ???
Möbius strip via wikipediajpg
So What?
• Stateless Client / Server rules give us
• Client Side Cache
• HTTP 1.1 conditional GET
• Implement Etags, If-Modified-Since
• Real savings time, $, and complexity
Most popular example:
Common Misconceptions
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
ReST is just CRUD
• Sure you can expose DB on web
• Too cute and simple right?
HTTP SQL CRUDPOST INSERT Create
GET SELECT Read
PUT UPDATE Update
DELETE DELETE Delete
It’s about favoring protocols and resources over APIs.
Refactor design to use new resources if you run out of HTTP methods
ExampleRequirment: A user can subscribe to an artist feed
ArtistWS.subscribeUserTo( User user, Feed feed )
Artist - GET, PUT, DELETE
Subscription - GET, POST, PUT, DELETE
Feed - GET, PUT, DELETE
User - GET, POST, PUT, DELETE
POST /subscriptions
artist=Art.1234feed=Feed.2345
email=false
Location: http://foo.com/subscription/Sub.3456
OR
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
• 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
• 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
WADL
• Don’t agree that WSDL2Foo is bad?
• OKAY, Use WADL
• WSDL like tool
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
Surprise, you’re soaking in it...
Everything we do over HTTP is “ReST”,
but we can build systems that work
with the natural form of the web
Call the police! TheseAPIs are a crime!
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
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/