1. The Why ofREST William Martínez Pomares Architect and R&D Manager Avantica Technologieswmartinez@avantica.net

2. Who Am I and Why I’m Here?

3. Agenda REST What? Application Types The Constrain Trade-off SOA Match Up Suitability

4. NO, REST is not… RPC API URI W.S. PROTOCOL! “An RPC protocol running over SOAP …” Charlie Kaufman and RamanathanVenkatapathy - Windows Azure™ Security Overview

5. YES, REST is…. “…architectural style for distributed hypermedia systems …” Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 5 “to minimize latency and network communication, while at the same time maximizing the independence and scalability of component implementations” Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 5

6. Styling Styles Style Definition Name Context Forces Problem Solution Consequences Style REST’s style “An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.” Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 1.5 Play Analogy

7. Application Types

9. Tight connections

10. High speed communication

11. Strong coupling

13. Weak coupling

14. High cost communication

15. User aware of composition

17. Standard Interfaces

18. Low frequency of interaction

19. Higher level processes

20. Reuse of Parts is rule

22. The …ilities

24. Improve Portability of UI

25. Scalability per simple server components

26. Independent evolutionServer Client

28. Concept degraded to hardware view

29. Interaction Model may confuse Messaging with RPCServer Client

31. All info needed is in message

32. Visibility: For Monitoring

33. Reliability: Partial recovery

34. Scalability: No server stored sessionServer Client

36. Takes away application control from server and places it into clients.Server Client

38. Reduces average latency.

39. Reduces processing on server by reusing results of processed data.

40. Can be multilevel Server Client

42. Implementation and storage cost

43. Requires client awarenessServer Client

45. Simple Architecture, better visibility

46. Decoupling.

47. Adds Independent Evolvability.Server Client Server

49. Impedance Mismatch since information is transferred in uniform format rather than most suitable.

50. May add processing cost due to transformation

51. Reduces visibility on InterfaceServer Client Server

52. Uniform Interface: REST Case Optimized for Large Grain Hypermedia Transfer Identifiable Resource concept Manipulation of resources by representations Self-descriptive messages Hypermedia as the engine of application state

53. The SOA Case Large Distributed Systems Legacy Heterogeneous Complex Imperfect Redundant Business service, process oriented Nicolai M. Josuttis,SOA in Practice, OREILLY

54. SOA – Process Oriented Messaging: Send data to a service for processing. RPC? No operation in protocol Business as a process, not as data Processes as resources Discoverable by repository, centralized No flow control. External or out of band Business semantics

55. REST – Hypermedia Oriented Messaging: Send/Receive representation. No RPC. Finite Operation set in protocol Not about business Datum as resources Discoverable by link, distributed Hypermedia as the State Engine Mixed semantics

56. SOA – REST Match Up Different types of applications REST as Special Service construction architecture Large distributed data Hypermedia related or Insensible to format transformation. Relaxed Security Independent evolution requirement Non processing intensive Non sensitive to performance hits, cacheable.

57. Questions?