1. Lecture 5 Web Service Program苏伟

2. Web 服务实现技术知识体系

3. Part I SOAP

4. Agenda
What is and is not SOAP?
SOAP Message Structure
SOAP Binding

5. What is SOAP? W3C Definition
Simple Object Access Protocol
A lightweight protocol intended for exchanging structured information in a decentralized, distributed environment
XML-based messages
Be independent of any particular programming model and other implementation specific semantics

6. Do I Need to know how SOAP works in detail as a Java Developer?
Yes
Understanding it will help you to build better application
Ex) Understanding how TCP/IP will help you build better TCP/IP application No
You will mostly likely use high-level API (JAX-RPC) to build Web applications
How SOAP works is hidden from developers

7. One-way message exchange paradigm
What is SOAP?
Stateless
One-way message exchange paradigm
Applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information
Be independent of the semantics of any application-specific data it conveys

8. Not a programming language
What SOAP is Not
Not a component model
So it will not replace objects and components, i.e. EJB™, JavaBeans™
Not a programming language
So it will not replace Java
Not a solution for all
So it will not replace other distributed computing technologies such as RMI

9. SOAP 1.2 is W3C recommendation SOAP 1.2 Part 1 defines
Where is SOAP?
SOAP 1.2 is W3C recommendation
SOAP 1.2 Part 1 defines
SOAP envelope
Protocol binding framework
SOAP 1.2 Part 2 defines
Data model for SOAP
Binding to HTTP

10. SOAP Message Structure

11. SOAP Message Structure

12. SOAP Message Envelope Embedded Information Header Body Namespaces
Encoding information
Header
Optional
Can be handled by intermediaries
Body
Mandatory
Handled only by ultimate receiver

13. SOAP Header (<env:Header>)
Used for extension
Context
Authentication
Transaction
Management
Many other sysem level semantics
Made of Header blocks (Header entries)
Most Web services standard activities are basically defining standard header entries for a particular domain

14. SOAP Body (<env:Body>)
Made of Body blocks (Body entries)
Consumed by Ultimate SOAP receiver
Carry end-to-end information
– Application data (XML document) (document
style)
– SOAP fault

15. SOAP document exchange example

16. SOAP RPC request — Example

17. SOAP RPC response — Example

18. SOAP Fault (<env:Fault>)
Used to carry error and/or status information
Four sub-elements
– faultcode
– faultstring
– faultactor
– detail

19. SOAP fault code values

20. SOAP Fault Example: Cause
<env:Envelope
xmlns:env='
<env:Header>
<abc:Extension1
xmlns:abc='
env:mustUnderstand='1' />
<def:Extension2
xmlns:def='
</env:Header>
<env:Body>
. . .
</env:Body>
</env:Envelope>

21. SOAP Fault Example: Result
<env:Envelope xmlns:env='
xmlns:f=' >
<env:Header>
<f:Misunderstood qname='abc:Extension1'
xmlns:abc='
<f:Misunderstood qname='def:Extension2'
xmlns:def='
</env:Header>
<env:Body>
<env:Fault>
<faultcode>MustUnderstand</faultcode>
<faultstring>
One or more mandatory headers not understood
</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>

22. Header Block or Body Block?
Decisions made at the time of application design
Header blocks may be targeted at various nodes that might be encountered along a message's path from a sender to the ultimate recipient
Intermediate SOAP nodes may provide value-added services based on data in such headers

23. SOAP Message Example: Travel Reservation

24. Example1: SOAP Message Travel Reservation (1/3)
<?xml version='1.0' ?>
<env:Envelope xmlns:env="
<env:Header>
<m:reservation xmlns:m="
env:role="
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime> T13:20: :00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>

25. Example1: SOAP Message Travel Reservation (2/3)
<env:Body>
<p:itinerary
xmlns:p="
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate> </p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
itinerary
[ai5tinErEri, i5t-] n. 路线

26. Example1: SOAP Message Travel Reservation (3/3)
<p:return> <p:departing>Los Angeles</p:departing> <p:arriving>New York</p:arriving> <p:departureDate> </p:departureDate> <p:departureTime>mid-morning</p:departureTime> <p:seatPreference/> </p:return> </p:itinerary> <q:lodging xmlns:q=" <q:preference>none</q:preference> </q:lodging> </env:Body> </env:Envelope>

27. Example2:SOAP Message Response Travel Reservation - Choices of Airport (1/2)

28. Example2:SOAP Message Response Travel Reservation - Choices of Airport (2/2)

29. Example3: SOAP Message Travel Reservation --Airport Information(1/2)
<?xml version='1.0' ?>
<env:Envelope xmlns:env="
<env:Header>
<m:reservation xmlns:m="
env:role="
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime> T13:36: :00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="
env:role= env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>

30. Example3: SOAP Message Travel Reservation --Airport Information(2/2)
</n:passenger> </env:Header> <env:Body> <p:itinerary xmlns:p=" <p:departure> <p:departing>LGA</p:departing> </p:departure> <p:return> <p:arriving>EWR</p:arriving> </p:return> </p:itinerary> </env:Body> </env:Envelope>

31. SOAP 1.1 Namespaces URI's Envelope Serialization mustUnderstand fault–
– Used for "version mismatch" check
Serialization –
mustUnderstand fault –
Upgrade –

32. SOAP bindings
SOAP binding relates to the protocol used to carry SOAP messages between SOAP nodes
Each pair of nodes in the message path may use a different protocol and hence a different binding
SOAP messages do not contain binding information
SOAP over HTTP is the most common binding for SOAP messaging

33. SOAP over HTTP The HTTP request message is split into two sections:
– Header:
In the case of SOAP/HTTP, contains addressing information for the recipient of the SOAP message
– Body :
In the case of SOAP/HTTP, contains the contents of the SOAP message
The HTTP header also contains a SOAPAction attribute, which identifies the request to the Web server as SOAP-related
In SOAP V1.2, SOAPAction is replaced by application/soap+xml type’s action parameter

34. SOAP HTTP example

35. Part II WSDL

36. Outline What and Why WSDL? Example WSDL Document
WSDL Document Elements
Importing & Authoring Style

37. What is WSDL? XML language for describing Web services
Web service is described as
–A set of communication endpoints (ports)
Endpoint is made of two parts
–Abstract definitions of operations and messages
–Concrete binding to networking protocol (and corresponding endpoint address) and message encoding

38. Where is WSDL Used? Discoverable through registry
Enables automation of communication details between communicating partners
–Machines can read WSDL
–Machines can invoke a service defined in WSDL

39. WSDL elements
These WSDL elements are contained within a single definitions element

40. The relationships between WSDL elements

41. WSDL Document Structure
<wsdl:definitions xmlns:wsdl="
targetNamespace="your namespace here"
xmlns:tns="your namespace here"
xmlns:soapbind="
<wsdl:types>
<xs:schema targetNamespace="your namespace here (could be another) "
xmlns:xsd="
<!-- Define types and possibly elements here -->
</schema>
</wsdl:types>
<wsdl:message name="some operation input">
<!-- part(s) here -->
</wsdl:message>
<wsdl:message name="some operation output">

42. </wsdl:message>
<wsdl:portType name="your type name">
<!-- define operations here in terms of their messages -->
</wsdl:portType>
<wsdl:binding name="your binding name" type="tns:port type name above">
<!-- define style and transport in general and use per operation -->
</wsdl:binding>
<wsdl:service>
<!-- define a port using the above binding and a URL -->
</wsdl:service>
</wsdl:definitions>

43. WSDL Namespaces

44. WSDL Document Example Simple service providing stock quotes
A single operation called GetLastTradePrice
Deployed using SOAP 1.1 over HTTP
Request takes a ticker symbol of type string
Response returns price as a float
Ticker:股票行情自动收录器

45. WSDL Elements Types – Data type definitions
– Used to describe exchanged messages
– Uses W3C XML Schema as canonical type system

46. WSDL Example: Types <definitions name="StockQuote"
targetNamespace="
xmlns:tns="
xmlns:xsd1="
xmlns:soap="
xmlns="
<types>
<schema targetNamespace="
xmlns="
<element name="TradePriceRequest">
<complexType>
<all>
<element name=”tickerSymbol" type="string"/>
</all>
</complexType>

47. </element> <element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </schema> </types>

48. WSDL Elements:Messages
– Abstract, typed definitions of data being exchanged
Operations
– Abstract description of an action
– Refers to an input and/or output messages
Port type
– Collection of operations
– Abstract definition of a service

49. Example: Messages, Operation, Port type
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
<!-- More operations -->
</portType>

50. WSDL Elements Binding Port Service
– Concrete protocol and data format (encoding) for a particular Port type
Protocol examples: SOAP 1.1 over HTTP or SOAP 1.1 over SMTP
Encoding examples: SOAP encoding, RDF encoding
Port
– Defines a single communication endpoint
– Endpoint address for binding
– URL for HTTP, address for SMTP
Service
– Aggregate set of related ports

51. Example: Binding, Port, Service
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="
<operation name="GetLastTradePrice">
<soap:operation
soapAction="
<input> <soap:body use="literal" /> </input>
<output> <soap:body use="literal" /></output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="
</port>
</service>

52. WSDL View of a Web Service

53. Web Service Invocation

54. Message Element Consist of one or more logical parts Syntax
<definitions .... >
<message name="nmtoken">
<part name="nmtoken" element="qname"? type="qname"?/>
</message>
</definitions>
– element attribute refers to an XSD element using a QName
– type attribute refers to an XSD simpleType or complexType using a QName

55. Example: Message Element
<definitions .... >
<types>
<schema .... >
<element name="PO" type="tns:POType"/>
<complexType name="POType">
<all>
<element name="id" type="string/>
<element name="name" type="string"/>
<element name="items">
<complexType>
<element name="item" type="tns:Item" minOccurs="0" maxOccurs="unbounded"/>
</all>
</complexType>

56. </element> </all> </complexType> <complexType name="Item"> <all> <element name="quantity" type="int"/> <element name="product" type="string"/> <element name="Invoice" type="tns:InvoiceType"/> <complexType name="InvoiceType"> <element name="id" type="string"/> </schema> </types>

57. <message name="PO"> <part name="po" element="tns:PO"/> <part name="invoice" element="tns:Invoice"/> </message> </definitions>

58. Types of Operations One-way Request/response Notification
– The endpoint receives a message
Request/response
– The endpoint receives a message, and sends a correlated message
Notification
– The endpoint sends a message
Solicit/response
– The endpoint sends a message, and receives a correlated message
solicit
[sE5lisit] v. 恳求

59. One-way Operation <operation name=”submitPurchase”>
<input message=”purchase”/>
</operation>

60. Request/Response Operation
<operation name=”submitPurchase”>
<input message=”purchase”/>
<output message=”confirmation”/>
</operation>
<fault message=”faultMessage”/>

61. Notification Operation
<operation name=”deliveryStatus”>
<output message=”trackingInformation”/>
</operation>

62. Solicit/Response Operation
<operation name=”clientQuery”>
<output message=”bandwidthRequest”/>
<input message=”bandwidthInfo”/>
<fault message=”faultMessage”/>
</operation>

63. Authoring Style Recommendation
Reusability and maintainability
Maintain WSDL document in 3 separate parts
– Data type definitions
– Abstract definitions
– Specific service bindings
Use “import” element to import necessary part of WSDL document

64. Example7A: http://example.com/stockquote/stockquote.xsd
<?xml version="1.0"?>
<schema targetNamespace="
xmlns="
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<element name="price" type="float"/>
</schema>

65. Example7B:
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="
xmlns:tns="
xmlns:xsd1="
xmlns:soap="
xmlns="
<import namespace="
location="
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

66. <message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePrice"/> </message> <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> </portType> </definitions>

67. Example7C: http://example.com/stockquote/ stockquoteservice.wsdl
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="
xmlns:tns="
xmlns:soap="
xmlns:defs="
xmlns="
<import namespace="
location="
<binding name="StockQuoteSoapBinding“ type="defs:StockQuotePortType">
<soap:binding style="document" transport="
<operation name="GetLastTradePrice">

68. <soap:operation soapAction="http://example
<input><soap:body use="literal"/> </input>
<output><soap:body use="literal"/></output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="
</port>
</service>

69. Part III UDDI

70. Agenda What is and Why UDDI?
UDDI Data Types and their structural relationship
UDDI Categorization
UDDI Programming model
UDDI over SOAP
Authoring Steps of WSDL, UDDI
Discovery, Binding and Invocation of a Service
Java API for UDDI

71. Service Architecture
UDDI defines a scheme to publish and discover information about Web services.

72. What is UDDI?
Programmatic registration and discovery of business entities and their Web services
Based on SOAP, HTTP, XML
Registry data
Business registrations
Service type definitions

73. Registry Data

74. Business Registration Data
“White pages”
address, contact, and known identifiers
“Yellow pages”
industrial categorizations
Industry: NAICS (Industry codes - US Govt.)
Product/Services: UN/SPSC (ECMA)
Location: Geographical taxonomy
“Green pages”
technical information about services

75. What uses UDDI? • Tool building client (Service Consumer)
– Browse or search registry
– Create a service proxy
• Tool publishing the service
– Generates WSDL
– Construct UDDI entries
• Application that needs dynamic binding
– Directly access UDDI
– Query can be pre-generated

76. Why UDDI or something like UDDI?
• Platform independent service
publication and discovery
• Enables dynamic service discovery

77. UDDI Adoption Phases • Phase 1: Experimental stage
• Phase 2: Private UDDI registry within an intranet (where we are today)
• Phase 3: Public UDDI registries with no coordination among them
• Phase 4: Public UDDI registries with coordination (i.e. replication)
• Phase 5: Value added registry services

78. Possible UDDI Topology

79. UDDI Data Types Business Entity Business Services Binding Templates
White Pages information
Business Services
Yellow Pages information
Binding Templates
Green Pages information
Contains references to tModels
tModels
Service Type Definitions
Contains references to WSDL documents

80. Business Entity Data Type
Top-level data structure that holds descriptive information about a business entity
Service descriptions and technical information are expressed within a businessEntity
Contains categoryBag

81. BusinessService

82. BindingTemplate

83. tModel Service type definition
Is expected to be created by industry consortium (as opposed to business entities)
Business entities create businessEntity's, businessService's, and bindingTemplate's
Shared by business entities
Has a reference to WSDL document
Enables quick search of all “business entities” which supports a particular service
Contains categoryBag

84. tModel Example
<tModel authorizedName="..." operator="..." tModelKey="...">
<name>StockQuote Service</name>
<description xml:lang="en">
WSDL description of a standard stock quote service interface
</description>
<overviewDoc>
<description xml:lang="en"> WSDL source document. </description>
<overviewURL> </overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="UUID:..."
keyName="uddi-org:types"
keyValue="wsdlSpec"/>
</categoryBag>
</tModel>

85. categoryBag Element
Allows businessEntity, businessService and tModel structures to be categorized according to any of several available taxonomy based classification scheme
NAICS (Industry code)
UNSPAC
D-U-N-S
ISO 3166
SIC

86. identifierBag Element
Allows businessEntity or tModel structures to include information about common forms of identification such as D-U-N-S numbers, tax identifiers, etc.
Can be used to signify the identity of the businessEntity, or can be used to signify the identity of the publishing party
Enhances the search behaviors exposed via the find_xx

87. Registry Data

88. Publishing Services

89. Programmer's API:Service Discovery

90. UDDI Runs “Over” SOAP

91. SOAP Message Example for get_serviceDetail request
<Envelope>
<Body>
<get_serviceDetail generic="1.0">
<serviceKey>6FD77EF6-E7D6-6FF6-1E41-EBC80107D7B5
</serviceKey>
</get_serviceDetail>
</Body>
</Envelope>

92. SOAP Message Example for get_serviceDetail response
<Envelope>
<Body>
<serviceDetail generic="1.0" operator="XMethods">
<businessService serviceKey="6FD77EF6-E7D6-6FF6-1E41-EBC80107D7B5"
businessKey="D1387DB1-CA06-24F8-46C4-86B5D895CA26">
<name>Currency Exchange Rate</name>
<description>Endpoint for service</description>
<description>IMPLEMENTATION: glue</description>
<description>CONTACT
<bindingTemplates>
<bindingTemplate bindingKey="0036DEBC-2F1B-EB84-09E2-3A4332C3E8B4"
serviceKey="6FD77EF6-E7D6-6FF6-1E41-EBC80107D7B5">
<description>SOAP binding</description>

93. <accessPoint URLType="http">http://services. xmethods
<accessPoint URLType="http"> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="uuid:D784C184-99B2-DA25-ED D11A12E5"/> </tModelInstanceDetails> </bindingTemplate> </bindingTemplates> </businessService> </serviceDetail> </Body> </Envelope>

94. UDDI, WSDL Relationships

95. UDDI, WSDL Relationships

96. Steps that could be Performed by Industry Consortium
Create WSDL document that contains abstract part of service definition (WSDL interface definition)
Create tModel that
makes a URL reference to WSDL interface definition
includes category information
can be shared by many business entities
Register the tModel to UDDI registry

97. Steps that are performed by Business entities
Find tModel for a particular service to offer from the UDDI registry
Determine the port address
Create bindingTemplate that
contains the port address
makes a reference to the previously found
tModel
Create businessService that refers to the bindingTemplate
Create businessEntity if necessary

98. Discovery of a Service Programmatically Through UDDI Browser
via Categorization (Yellow paging)
via identity information (White paging)
via Drill-down
via name patterns
Through UDDI Browser

99. Binding to and Invocation of a Service
Obtain WSDL interface information from the tModel
Obtaining port address from bindingTemplate
Construct WSDL instance definition (WSDL document with concrete binding and port address)
Create service proxy from WSDL
Invocation pattern
Cache the bindingTemplate info for a service
If call to web service fails, re-check info in UDDI

100. Issues of UDDI
How do you know if the data you get is valid, legitimate, and up to date?
How do you measure quality of data?
How do you make sure only the qualified entities register their service information (authentication)?
How do you provide access control to the data in the registry?
How do you synchronize the data in multi-registry environment?

101. Current Status of UDDI
No production-quality deployment and usage in a public domain
Only experimental UDDI servers are present
Limited usage within an Intranet

102. JSR 93: Java™API for XML Registries (JAXR)
API to expose heterogeneous and distributed XML registries:
ebXML, UDDI, …
Publish, subscribe, query, associate…
Web service metadata
Schemas
Business processes
Documents

103. JUDDI Open source implementation of UDDI V2
Runs over any Servlet 2.3 compliant container

104. Part IV REST

105. Topics
How we use Web today?
What is REST?
Why REST?
REST vs. SOAP

106. Everything is accessed thru URLs

107. REST REpresentational State Transfer
Name coined by Roy Fielding in his Ph.D thesis*
Architectural Style of the Web

108. Characteristics of REST
RESTful services are stateless
Each request from client to server must contain all the information necessary to understand the request
RESTful services have a uniform interface
GET, POST, PUT, and DELETE
REST-based architectures are built from resources pieces of information) that are uniquely identified by URIs

109. Characteristics of REST (Continued)
In REST system, resources are manipulated through the exchange of “representations” of the resources
For example, a purchase order resource is represented by a XML document.
In a RESTful purchasing system, each purchase order is made through a combination HTTP POST method with XML document, which represents the order, sent to a unique URI
In REST system, communication occurs primarily through the transfer of representations of resources
State is maintained within a resource representation
REpresentational State Transfer

110. REpresentational State Transfer

111. Everything (Every Resource) has an ID
ID is a URI

112. Multiple Representations
• Offer data in a variety of formats
>XML
>JSON
>(X)HTML
• Support content negotiation
>Accept header
GET /foo
Accept: application/json
>URI-based
GET /foo.json

113. What Makes Up a REST Request?
• Resources (nouns)
>Identified by a URI, For example:
>
• Methods (verbs) to manipulate the nouns
>Small fixed set: GET, POST, PUT, and DELETE
• Representation is how you view the State
>data and state transferred between client and server
>XML, JSON...
• Use verbs to exchange application state and representation

114. HTTP Request/Response As REST

115. CRUD Operations are Performed through HTTP method + URI

116. HTTP Methods: GET • GET to retrieve information
• Retrieves a given URI
• Idempotent, should not initiate a state change
• Cacheable

117. HTTP Methods: POST • POST to add new information
• Add the entity as a subordinate/append to the POSTed resource
>POST /music/beatles

118. HTTP Methods: PUT • PUT to update information
• Full entity create/replace used when you know the “id”
>PUT /songs/

119. • Remove (logical) an entity
HTTP Methods: DELETE
• Remove (logical) an entity
>DELETE /songs/heyjude

120. Common Patterns: Container, Item Server in control of URI path space
• List container contents: GET /items
• Add item to container: POST /items
>with item in request
>URI of item returned in HTTP response header
>e.g. Location:
• Read item: GET /items/itemid
• Update item: PUT /items/itemid
>with updated item in request
• Remove item: DELETE /items/itemid
• Good example: Atom Publishing Protocol

121. Common Patterns: Map, Key, Value Client in control of URI path space
• List key-value pairs: GET /map
• Put new value to map: PUT /map/{key}
>with entry in request
>e.g. PUT /map/dir/contents.xml
• Read value: GET /map/{key}
• Update value: PUT /map/{key}
>with updated value in request
• Remove value: DELETE /map/{key}
• Good example: Amazon S3

122. Why REST ? • REST base services are easy to work with • Uniformity
>Clients do not need to use specialized API
>Clients just use standard HTTP
>You can use browser for experimentation and testing
• Uniformity
>URI is a uniform way to identify resources
>HTTP uniform interface to manipulate resources
• Scripting language friendly
>Easy to consume and develop

123. REST vs “Traditional” Web Services
>Few URIs (nouns), many custom methods (verbs)
>musicPort.getRecordings(“beatles”)
>Uses HTTP as transport for SOAP messages
• RESTful web service
>Many resources (nouns), few fixed methods(verbs)
>GET /music/artists/beatles/recordings
>HTTP is the protocol

124. SOAP Service and REST Resource
• SOAP based web services is about services SOA
>Stock quote service
quoteService.purchase(“sunw”, 2000, 6.0f);
• Resource-Oriented Architecture (ROA)
>Stock quote resource
>Resources are manipulated by exchanging representations
>Eg. purchasing stock
>Manipulate my portfolio resource
>Handle a POST in a stock resource that I own
>POST /mystocks/sunw

125. Thank you！