Joachim Tuchel gives a short introduction to RESTful Web Services and contrasts its basic concepts to "classic" Web Services. He shows how the Server Smalltalk Feature of VA Smalltalk can be used to implement RESTful Clients and Servers, and how these building blocks can be used in a Seaside-based Web Application. This presentation was given at the VA Smalltalk Summit 2009.

1. How to integrate
your applications
with today‘s
technology trends
RESTful Web Services
in VA Smalltalk
Joachim Tuchel
www.objektfabrik.de
© 2009 by Joachim Tuchel

2. Agenda
• About me and objektfabrik
• „Classic“ Web Services
• RESTful Web Services: What‘s different?
• RESTful Web Services with VA Smalltalk
• DEMO: REST Clients & Server
• Questions

3. About me
• Founder and director of objektfabrik
• Business Informatics (Banking)
• Smalltalk since 1996
(VA Smalltalk,VisualWorks and Squeak)
• Java since 2004
• jtuchel@objektfabrik.de

4. About objektfabrik
• Founded 1999 in Ludwigsburg, Germany
• Training, Consulting, Professional Services
• Application and System architecture
• Software Development in Smalltalk, Java,
Ruby and Objective-C
• Instantiations Business Partner since 2006

5. Training offerings
• Object Technology Basics
• Smalltalk Basics
• VA Smalltalk Application Development
• Advanced VA Smalltalk workshops
(Packaging, Config Management, SUnit...)
• New in 2009: Seaside

6. Web Services
and VA Smalltalk

7. Web Services
• Uses HTTP/S POST for transport
• in theory uses any transport protocol
• XML Messages
• SOAP-Envelopes
• Namespaces
• Many standards / schemas available

8. Web Services
• W3C Standard
• Huge set of domain/industry specific and
vertical (cross industry) standards (WS-*)
• Large selection of tools and vendors
• „Enterprise integration technology“

9. Web Services and VA
Smalltalk
• Supported by VA Smalltalk since V 5.5
• Based on Server Smalltalk
• Constantly improved in 6.x, 7.x and 8
• Expose a Smalltalk method as a service
• Consume a service in Smalltalk

10. What‘s wrong with
Web Services
• Heavy weight standard
• One size fits all (by being large enough)
• Can be very complicated to deploy and
debug
• Very complex XML structures
• Way too heavy for simple jobs

11. RESTful Web Services

12. RESTful Web Services
• REST = Representational State Transfer
• What is it?
• Not a standard
• It‘s an architecture
• Simplicity and Reuse of existing Standards
like the HTTP (=Protocol) are design goals

13. REST is everywhere
• Amazon Web Services
• Simple Storage System (S3)
• SimpleDB - SQL - like Database
• eBay Shopping APIs
• PayPal

14. REST is everywhere
• Google REST APIs
• Search, Blogger, Maps, Analytics...
• Yahoo! REST APIs
• Finance, YQL, Travel, Weather...
• Twitter, Technorati, all over „Web 2.0“
• Apache CouchDB

15. REST is everywhere
• REST is part of „The Web“ today
• REST is used for
• Integration
• Distribution
• Scaling
• Mashups

16. Basic Concepts

17. Basic Concepts
• RESTful Web Services are about Resources,
not about Services (operations)

18. Basic Concepts
• RESTful Web Services are about Resources,
not about Services (operations)
• Addressability: Every Resource has a uniform
name = URI

19. Basic Concepts
• RESTful Web Services are about Resources,
not about Services (operations)
• Addressability: Every Resource has a uniform
name = URI
http://myhost/users/joachim/todolists...

20. Basic Concepts
• RESTful Web Services are about Resources,
not about Services (operations)
• Addressability: Every Resource has a uniform
name = URI
http://myhost/users/joachim/todolists...
• Statelessness: Server doesn‘t save any
application state ➠ Scalability

21. Basic Concepts
• Operations defined in HTTP standard
• Create: POST a new resource
• Read: GET a resource
• Update: PUT a resource
• Delete: DELETE a resource
• References to objects are IDs or hyperlinks

22. What‘s a Resource?
• •
Customer Database Transaction
• •
Purchasing Order Flight Booking
• •
Line Item Message
• •
Hotel Room Dataset (RDB/OODB)
• •
Hotel Room Reservation any entity we deal with in
our systems
• User Account

23. What‘s a Resource?
• Not necessarily a Business Object!
• Not all aspects need to be transported
between applications
• Some aspects belong to a different
Business Object (save bandwidth)
• References become IDs or Hyperlinks

24. Basic Concepts

25. Basic Concepts
Client

26. Basic Concepts
Resource
Client
Server

27. Basic Concepts
GET /users/Joachim
HTTP Request
Resource
Client
Server

28. Basic Concepts
GET /users/Joachim
HTTP Request
Resource
Client
Server
HTTP Response
HTTP/1.1 200 OK
Content-Type: application/xml
<?xml version=...>
<User firstname=“...

29. Basic Concepts
GET /users/Joachim
HTTP Request
Resource
Client
Server
HTTP Response
HTTP/1.1 200 OK
Content-Type: application/xml
<?xml version=...>
<User firstname=“...
Contents can be
XML, JSON, CSV, Binary Data
...any MIME-Type

30. HTTP and Response
Codes: GET
• 200 OK
• 400 Bad Request
• 401 Unauthorized / 403 Forbidden
• 404 Not found
• 500 Internal Server Error

31. HTTP Methods and
Codes: POST
• 201 Created
• 409 Conflict
• 415 Unsupported Media Type
• 500 Internal Server Error
• Many more ...

32. Useful Advanced
HTTP - Features
• If-Modified-Since / Last-Modified / 304 Not
Modified for caching
• Cache-Control (read-only objects or
infrequently changing objects)
• Content-Type to determine marshalers
• Accept-Ranges / Content-Range for partial
loading of long lists etc.

33. Benefits of bare HTTP?
• Reduced Complexity: HTTP is easy
• Advantage in Development & Maintenance
• Uniform interface (HTTP) to every
resource
• More flexibility: serving/accepting
Resources instead of exposing a set of
operations (➠Mashups)

34. RESTful Web Services
with VA Smalltalk

35. Ingredients for
RESTful Web Services
• HTTP communications (Possibly HTTPS)
• Transport format for resource data
• XML, JSON, plain ascii
• Marshalling and unmarshalling on both ends
• Naming Service (URI ➠ Resource ➠ URI)

36. VAST provides all the
Building Blocks
• Server Smalltalk
• HTTP Client and Server
• Highly configurable and extendable on
many levels
• Scalable (Multithreading by default)
• Mature (~10 years) and in use
• XML marshalling

37. Building a
REST Client
• Extends SstHttpClient
• Adds xml marshalling (or other marshalling
like)
• Wraps simple HTTP requests and handles
response codes
• Optional: Session / cookie handling,
caching ... (Maybe not „pure“ REST)

38. PRESTON client
• getResourceNamed: aURI
queryParameters: aDictionary
• postResource: anObject
toResourceNamed: aURI
• deleteResourceNamed: aURI
• getOptionsForResourceNamed: aURI
• handles session cookies (optional)

39. PRESTON client
• Mapping between Resource (e.g. XML) and
Smalltalk objects
• Optional caching (URI → object)
• Proxies for hyperlinks
(linked resource is only fetched if needed)
• Can act as database client to a RESTful web
service

40. Building a
REST Server
• Extends several components of SST HTTP
Server
• Is very similar to a servlet container (it
serves resources with a certain URI)
• Adds marshalling, naming and more

41. SST Building Blocks
SstServerApplicationContext
SstBasicServer containerKey
sessionManagerConfig.
attributes
applicationContexts
sessionManagers
initializeRequest:
handlesRequest:
startUp SstHttpSessionManager
shutDown
processClientRequest:
basicProcessRequest:
createSessionForRequest:
processRequest:
createCookieForSession:
SstHttpServer
cookieFromRequestHeader...
SstHttpServletEngine

42. PRESTON Server
SstServerApplicationContext
SstBasicServer containerKey
sessionManagerConfig.
attributes
applicationContexts
sessionManagers
initializeRequest:
handlesRequest:
startUp SstHttpSessionManager
shutDown
processClientRequest:
basicProcessRequest:
createSessionForRequest:
processRequest:
createCookieForSession:
SstHttpServer
cookieFromRequestHeader...
PrestonResourceManager
PrestonApplicationContext
supportedHttpMethods
resourceManagers
PrestonServer
pathSegment
xmlMappingSpec
rootObject
handleGETRequest..
handlePostRequest...

43. Demos
• Yahoo! Traffic Client
• Yahoo! Traffic Client on a Seaside Server
• Todomatic Server & Client

44. GET MapsService/V1/trafficData
with request parameters
PRESTON Client
Yahoo! Traffic REST API
http://local.yahooapis.com/
HTTP
Application Logic
Response
with XML
Sample Request URI:
http://local.yahooapis.com/MapsService/V1/trafficData?
appid=YdnDemo&street=701+First+Ave&city=Sunnyvale&state=CA
VA Smalltalk Image

45. ith
eventually w
ody
a message b
ML
containing X
document
GET users/joachim/todolists
POST users/joachim/todolists
HTTP Client
OODB Todomatic PUT users/joachim
* Web Browser
RESTful Server * PRESTON Smalltalk client
VA Smalltalk Image * Any other HTTP Client
TodoLists and
TodoItems nse
HTTP Respo
l
with optiona
ent
XML Docum
User TodoList TodoItem

46. Summary

47. RESTful Web Services
• Anywhere on the web today and growing
• Far less complex than Web Services
• HTTP standard all the way down
• Can be used for Internet applications as
well as for internal systems
• Integration
• Scaling

48. VA Smalltalk and
RESTful Web Services
• Most Web Services are CRUD operations
• Integration today mostly means combining
HTTP with XML or other text formats
• VA ST provides all the building blocks
• Some extensions needed
• Can be combined with Seaside easily
• Mashup your own services

49. Questions?
chel
im Tu g 1
Joach erwe
Flied rmany
g, Ge ik.de
sbur tfabr
dwig bjek
40 Lu el@o ik.de
tfabr
716 tuch
objek
j
ww.
w
More info on my blog:
www.joachim-tuchel.de