1. Controling instrument in the RESTful way
Good morning ladies and gentlemen. My name is Tony, and I’m currently working for the Bragg Institute on a scientific software package called GumTree.
Tony Lam
Bragg Institute

2. Agenda What is REST? How instruments be controlled in the RESTful way?
This talk is going to answer few basic questions:
* What is REST?
* Can REST be applied to instrument control, and how? What are the advantages of using REST? Is there anything we cannot do with REST?

3. Representational State Transfer (ReST) is an Architectural Style
for distributed hypermedia systems
- Roy Fielding’s doctoral dissertation (2000)
Representational state transfer is an architectural style.
You may heard of REST or RESTful web services in many sources, but strictly speaking REST is not a standard nor a method to build web services.
REST is a collection of architecture principles for how network resources are defined and manipulated.
The term REST is first introduced by Roy Fielding’s PhD Thesis in Roy Fielding is one the principle authors of the HTTP specification.
The World Wide Web is the key example of a RESTful design. We will soon learn how REST works on top of the HTTP protocol. Hopefully by adding REST support on your application will end up with a system that leverage today’s Web technologies, such as Web 2.0, to your benefit.

4. Architectural Style Glasgow City Chambers, UK
First of all, why do we care about architecture? Architecture is all about abstraction.
As you may see, buildings with same architectural style share common characteristics, although they may not look exactly the same.
<click> … different architecture
In the context of software engineering, architectural style explicitly places constraints on the system. Each constraint is a trade-off to fulfil particular design goal.
REST design focus on portability and scalability.
Glasgow City Chambers, UK
Queen Victorian Building, Sydney

5. Constraint 1: Client-Server
Protocol connector
Client
uniform interface
(eg HTTP)
Server
Constraints:
Client-Server
Rationale:
Separation of concern
A RESTful system is a client-server system. Separation of concerns is the principle behind the client-server constraints, where server can focus on robustness without worrying the instability of the user interface code.
There starts to define some building blocks here
Component: client, server
Protocol: Uniform protocol (eg HTTP)
Connector: eg HTTP lib

6. Constraint 2: Stateless
Protocol connector
Client
Server
Client
Client
Constraints:
Client-Server
Stateless
Rationale:
Separation of concern
Scalability
Client-server approach makes multi-platform client possible. However, to increase the scalability of the system, REST constrains the connection on the server side to be stateless. That is, the server maintain no session information of whatever client it connects to.

7. Constraint 3: Cacheable
Protocol connector
… with cache $
Client $
Server
Client $
Client $
Constraints:
Client-Server
Stateless
Cacheable
Rationale:
Separation of concern
Scalability
Efficiency
Cache support on the communication channel minimise the amount of traffic in the network, and hence increase system efficiency with reduced latency.

8. Constraint 4: Layered Constraints: Rationale: Client-Server Stateless
Protocol connector
… with cache $
Client $
Gateway
Firewall
Server
Legacy System
Client $ $
Legacy
Protocol
Client $
Constraints:
Client-Server
Stateless
Cacheable
Layered
Rationale:
Separation of concern
Scalability
Efficiency
Encapsulation of legacy services
Load balancing
Finally, we Intermediaries: proxies, gateways, firewall can be introduced at various points in the communication without changing the interface between components.

9. Concept 1: Resource
Any information that can be named is abstracted to “resource”
Examples: document, image, database record, application state and functionality, etc
Every resource is uniquely addressable
via Uniform Resource Identifier (URI) in HTTP
URIs are used as hypermedia links to identify other resources
The core of REST is the concept of resource. Virtually everything that can be named is abstracted as resource.
For example, a web page, image file, a collection of database record, and even application’s functionality.
Resource can be hyperlinked to other resources, as the way to discover other resources

10. Examples Database record of the user #1234
Last name of the user #1234
Today’s Sydney weather or
URI is a hierarchical structure.

11. Examples in Scientific Domain
CONTROL:
Temperature reading of temperature controller 1
DATA STORAGE:
The first dataset in the NeXus file nx0094 from the repository
COMPUTATION:
Summation of 2 + 3
Any hierarchical resource fit naturally with URI, for example NeXus.
In a more extreme case, we can express any calculation result as resources. Hence, REST can be used indirectly as calculation engine.

12. Concept 2: Representation
Resources are manipulated by exchanging their representations between components (client and server)‏
Representation captures the state of a resource, or the actual information if the resource is a document
Each resource can have multiple representation
Representation has associated content type, eg HTML
Information or state of a resource is captured in form of representation.
When resources are manipulated, such as read or create operation, those presentations of resource are exchanged between components of the network.
Each resource can be expressed in different representations. Depending on your client, server may accept and response to specific representation format.

13. A circle with URI http://example.com/circle
Examples
A circle with URI
GET /circle HTTP/1.1
Host: example.com
Accept: image/jepg
GET /circle HTTP/1.1
Host: example.com
Accept: text/XML
GET /circle HTTP/1.1
Host: example.com
Accept: application/x-javascript
<shape color=“blue”>
<cartesian>
x^2 + y^2 = 4
</cartesian>
</shape>
Depending on the request content type, a circle on the network can be represented as an image, an equation, or parameterized properties. They are basically more or less describing the same thing.
{centre:0, radius:2, colour:”blue”}

14. Examples in Scientific Domain
Depending on your client application, you may read the temperature controller history in the following forms:
Raw numbers for processing
URI:
Result: Comma separated value (CSV) of entire history
GUI Status Display
URI:
Result:
Filtered GUI Status Display (limited to show past 5 min)
URI:

15. (in different representations)
State Transfer
Client
Server
request a a b c d e 3 1 2 3 4 a a a a
response
State of resource
(in different representations)
Actual
Resources
The word “Representational State Transfer” (REST) comes from how the state of resources (in various representations) flow within the client application.

16. Concepts 3: Uniform Interface
All resources use a set of standard operations for transferring state between client and resource.
Easy to use in every programming language
How to transfer?
Other methods in HTTP: HEAD, OPTION

17. HTTP Methods HTTP method CRUD equivalent Safe Idempotent
Object-Orientated API
GET
Read Y
resource.get()
PUT
Update (create) N
resource.put(request)
POST
Create (update, delete)
resource.post(request)
DELETE
Delete
resource.delete()
Safe: no changes to any data on the server (no obligation)
Idempotent: repeat without changing resource

18. Assume those resources are available:
/sample_environments
GET – list all sample environments (links)
PUT – unused
POST – register new a sample environment
DELETE – unused
/sample_environments/{id}
<<interface>>
Resource
GET – get sample environment details
PUT – unused
POST – unused
DELETE – remove sample environment
GET
PUT
POST
DELETE
/sample_environments/{id}/target
GET – get sample environment target
PUT – set sample environment target
POST – unused
DELETE – unused
/scanners/2theta_scanner
GET – get scan status
PUT – unused
POST – run 2 theta scan
DELETE – unused
Those methods mean differently in different context.
Let’s say we have those following resources available in our server.
Assume those resources are available:
 sample environment listing resource
<-- temp controller #1 resource
<-- temp controller #1 target resource

19. HTTP Report Status
HTTP provides rich set of standardised return status code for error handling.
Successful Codes (2XX):
200 OK
201 Created
202 Accepted
204 No Content
Redirection Codes (3XX):
301 Moved Permanently
304 Not Modified
Client Errors (4XX):
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
Server Errors (5XX):
500 Internal Server Error
Hopefully we
Security is supported in HTTP by authenticating via login name and password.
Testing can be done with just a web browser!

20. Hopefully you remember three main concepts of REST:
Resource
Representation
Uniform interface
So, are we there yet? Almost!

21. Traditional Instrument Control
Desktop Client
(Java + Control System Adapter)
drive(new_set_point)
read(current_value)
Instrument
Network
In the traditional approach, communication is achieved by using standard interface such as CORBA, RMI, or control system specific protocol like EPICS and TANGO. This requires on the client to have the protocol library in a particular language binding. Although popular protocols provide binding with major programming language such as C, Java and Python, certainly no protocol library was wide support like HTTP.
Device Server

22. RESTful Instrument Control
Protocol connector
Traditional
Desktop Client
(Java + Apache HTTP client)
… with cache $
POST
new set point
GET
current value
REST Server $
drive(new_set_point)
Instrument
Network
Let’s see how we use the REST principle to build a RESTful system.
We place a layer of abstraction in the network to support the uniform interface. Since the network is layered, no modification on the server side is required.
Device Server
read(current_value)

23. RESTful Instrument Control
Protocol connector
Traditional
Desktop Client
(Java + Apache HTTP client)
… with cache $
Resource Management Tool
DELETE
existing device
POST
Scripting
Application
(Python + httplib)
GET
PUT
new device
REST Server $
Rich Internet Application
(Adobe Flex + mx:HTTPService)
Instrument
Network
Because of using the standard interface, HTTP, supporting clients with different languages and runtimes can be very easy.
No special library is required for communication.
To complete the picture, we can also add a resource management tool that xxxx
Device Server
GET
Browser
(Firefox + Poster plugin) $

24. Instrument Control in Web 2.0 Style
Client A
CLOUD
Amazon S3
REST Server
Data Storage
Client B
Computation Box
Amazon E2
REST Server
Client C
Instrument
Network
RESTful CS Server
Web 2.0
Mash up
REST helps to leverage the web architecture
Device Server $
Client D
Yahoo!
REST Server
Web Service
(news, map, weather) $

25. FAQ Is REST just another RPC technology like XML-RPC or CORBA?
Does REST support publish / subscribe pattern?
REST is categoried as Resource-Orientated Architecture
Service-Orientated Architecture, SOA
HTTP
Short answer is NO. It works fine with another protocol like FTP or any proripity protocol, although mismatch may occur.

26. FAQ (cont.)
Does my control system need to be refactored completely to adapt REST?
Does REST work with HTTP only?
Eg Yahoo: SOAP and REST simultanously
Example:
SICS, TANGO, EPICS, CIMA
Does REST work with HTTP only - > NO

27. References Internet Representational State Transfer (Wikipedia)
How I Explained REST to My Wife
InfoQ: A Brief Introduction to REST
Architectural Styles and the Design of Network-based Software Architectures (Roy Fielding's doctoral dissertation)

28. References (cont.) Books Presentations
RESTful Web Services (O’Reilly, 2007)
Presentations
ReSTful OSGi Web Applications Tutorial
Real-time Web 2.0: Evolution of Middleware for Grid-based Instruments and Sensors