Applied REST. Brian Sletten Bosatsu Consulting, Inc.

Transcription

1 Applied REST Brian Sletten Bosatsu Consulting, Inc.

2 Speaker Qualifications Over 13 years of software development experience Has own software consulting company for design, mentoring, training and development Currently working in Semantic Web, AOP, Grid Computing, P2P and security consulting 2

3 Agenda Why Do We Care? REST Concepts REST Examples REST Motivation Building RESTful Interfaces Conclusion 3

4 Why Do We Care?

5 WS-Dissatisfaction Conventional Web Services are often too difficult for non-trivial tasks (real complexity) too complex for trivial tasks (artificial complexity) RPC-based Web Services are mythically interoperable and time/process coupled in painful ways 5

6 What Makes SOAP Difficult? Will the real SOAP intended use please stand up? Remote Procedure Calls Application Protocols Tunneling using existing Application Protocols (HTTP) 6

7 Security Abominations Tunneling SOAP through firewalls is a questionable practice HTTP is not a transport protocol! Intermediaries can only route to endpoints No actionable semantics in RPC interactions 7

8 SOA Service-Oriented Architecture (SOA) An architectural style promoting loose coupling among software participants Companies have rigid definitions of what constitutes a SOA Must Publish/Find/Bind = UDDI/WSDL/SOAP? 8

9 SOA What? SOAP 1.2 and Doc Lit are improvements, but are they necessary? What is the problem we are trying to solve? We already have an example of a scalable software architecture for network applications 9

10 Return of the Vendors Vendors are fine However, too many are trying to sell you the same thing repackaged without thinking about what we are trying to solve CORBA ORB and tools EJB Container SOA-complexity managing tools 10

11 If You Build It......they will use REST Anecdotally, 85% of Amazon s users choose REST over SOAP 11

12 REST Concepts

13 What is REST? REpresentational State Transfer (REST) An architectural style based on certain constraints designed to elicit properties of scalability and extensibility An idealized notion of how the early Web should work Helped drive the way it eventually did work More than just URLs! 13

14 Resource Anything that can be named/referred to Files Services Concepts What is returned can change over time Consider the trunk version of a file in Subversion 14

15 Resource Abstraction Generality by allowing different types Static or Dynamic Flexibility through late binding negotiation of type Abstract references that do not necessarily need updating when the underlying format changes GIF->PNG 15

16 Resource Identifier Means of naming a resource Standard syntax that allows various schemes Known as URIs (or IRIs) Orthogonal to satisfying the reference One of the main missing pieces of normal web services 16

17 Representation A particular deferencing of a Resource Identifier to a Resource at a particular time Think the file index.html or Today s Slashdot Page A byte-stream tagged with metadata Could change based on request or processing/display capabilities of client Firefox vs. WAP 17

18 Resource/Representation Metadata Accompanies a Representation Allows intermediaries to make decisions (caching) Helps clients know how to display the Resource Includes MIME Type Last modified date 18

19 REST Verbs Design decision to minimize the breadth of the interface RPC is completely open-ended from an action perspective 19

20 GET Retrieve a Resource 20

21 POST Create a Resource 21

22 PUT Update a Resource 22

23 DELETE Remove a Resource 23

24 REST Examples

25 Why Not Apache? Tomcat? IIS? Jetty? All of these web servers can certainly expose RESTful interfaces Once you look under the hood, however, it becomes more complicated 25

26 NetKernel Ground up generalized architecture built around REST Microkernel maps requests for resources into the software components that will satisfy the requests Benefits from the architectural properties we have discussed 26

27 RESTlet Lightweight Java-based REST framework Alternative API to Servlets for cleaner match to REST concepts Support for filters, authentication logging, blocking and non-blocking IO 27

28 REST Motivation

29 The REST is History Concepts are based on Roy Fielding s work - On his Ph.D. Thesis Architectural Styles and the Design of Network-based Software Architectures - On HTTP 1.0/1.1 Standards - On Apache, libwww and related projects 29

30 Software Architecture A software architecture is defined by a configuration of architectural elements components, connectors, and data constrained in their relationships in order to achieve a desired set of architectural properties. -- R.F. Thesis 30

31 Architectural 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. -- R.F. Thesis 31

32 Architectural Effects Choice of a particular architectural style has consequences for how components communicate Affects overall growth potential and performance of a system 32

33 Architectural Properties Of Interest Performance Scalability Generality Simplicity Modifiability 33

34 REST Goals Provide architectural guidance Minimize latency of network software applications Maximize component independence and scalability Support extensibility through small, welldefined abstract interfaces 34

35 Client-Server Supports Separation of Concerns (SOC) UI code can be localized in client Backend logic can be localized in server (reused by different clients) 35

36 Client-Server 36

37 Stateless All parameters travel with request No session information maintained on server Improves scalability through load-balancing Improves visibility of intermediary processors 37

38 Stateless Client-Server 38

39 Replication Decentralization of data Can be wholly or partially copied around Improves accessibility and scalability Improves user perception of performance Introduces need to keep data in synch 39

40 Cache Form of replication when external data set is too large to copy locally Results of individual requests can be captured and re-served later 40

41 Uniform Interface Improves generality, simplicity and reusability Can cause performance issues when data needs conversion to/from standard formats but REST tries to optimize for average Web data types 41

42 Stateless Client-Server w/ Cache and Uniform Interface 42

43 Layered System Managed dependencies between layers Improved modifiability by compartmentalizing visibility to neighboring layers 43

44 Layered Stateless Client-Server w/ Cache and Uniform Interface 44

45 REST Properties Based on figure from R.F. s thesis 45

46 Building RESTful Interfaces

47 What is Controversial URI Opacity How much meaning should there be in URIs? How do naming schemes affect intermediary processing? make the Web brittle? differ by language context? 47

48 tbl on URI Opacity When you are not dereferencing you should not look at the contents of the URI string to gain other information

49 Roy on URI Opacity "REST does not require that a URI be opaque. The only place where the word opaque occurs in my dissertation is where I complain about the opaqueness of cookies. In fact, RESTful applications are, at all times, encouraged to use humanmeaningful, hierarchical identifiers in order to maximize the serendipitous use of the information beyond what is anticipated by the original application." message/

50 UnREST REST is largely defined by a small number of semi-formal specifications, a larger number of secondary publications and writings, and the collected design notes, anecdotes, and essays of Tim Berners-Lee. Among these artifacts there are a number of contradictions, a number of ambiguities, and perhaps at least some assertions and principles which are not sufficiently supported. Where certain principles and assertions can be formalized and their observable impact quantifiably understood, REST is solid... My beef with the Opacity Axiom (hereafter, "the axiom") is that it (needlessly, IMHO) discards the important and useful concept of structured naming and semantically rich namespaces. In filesystems research and elsewhere over the last decade or two (described in slightly more detail in OpacityReconsidered) many researchers have recognized the power and utility gained by enriching the structure and semantics of names and namespaces. The Web, curiously, runs absolutely counter to this trend. --Jeff Bone ( 50

51 Encoding Meaning in Structure Which is more meaningful? (To Whom?)

52 Hierarchies Organizational Temporal Topical? 52

53 Hierarchical + Non-Hierchical Organizational Temporal Topical? 53

54 When You Aren t Sure Use query strings for non hierarchicallyrelated attributes 54

55 Pragmatic REST At a minimum, URIs must be able to be treated opaquely Hierarchical spaces are conveniently represented through the path portion of a URI Non-hierarchical attributes should be delegated to the query parameters 55

56 What Isn t Controversial Do not rely on sessions or other state at the application level Use nouns, not verbs Don t abuse GET! No side effects Don t abuse POST! Limit use to creation, not conversational GET 56

57 Real World Examples Amazon ebay Yahoo! Bloglines Atom Ruby on Rails (1.2)

58 Conclusion

59 Open Issues Describing RESTful services to clients Publishing metadata about RESTful services Transactions Conversational State 59

60 Main Points REST may not be the only answer, but it is often the more straightforward answer REST is more than using URLs to access web services It is the deliberate application of architectural constraints to elicit the properties of scalability, simplicity, modifiability, generality and performance 60

61 Selling REST REST started off as the idealized notion for a scalable network software application architectural style It has become the architectural style of the Web Software built around REST principles demonstrates similar characteristics (NetKernel) Nothing necessarily to buy, not a steep learning curve 61

62 References Resource Roy Fielding s Thesis RESTWiki Paul Prescod s REST Thoughts NetKernel RESTlet Flickr Hammock Picture Location