5. what?
• Representational state transfer (REST) is a style
of software architecture for distributed systems
such as the World Wide Web. REST has
emerged as a predominant web API design
model.
• Representational State
Transfer REST Roy Fielding
2000
5
6. the Author of REST
• Fielding HTTP 1.0
1.1 Apache
Apache
•
• REST
6
11. key goals
• Scalability of component interactions
• Generality of interfaces
• Independent deployment of components
• Intermediary components to reduce
latency, enforce security and encapsulate
legacy systems
11
32. Guiding principles of
the interface
• The uniform interface that any REST interface must provide is considered fundamental to the design of
any REST service.
• Identification of resources
• Individual resources are identified in requests, for example using URIs in web-based REST systems.
The resources themselves are conceptually separate from the representations that are returned
to the client. For example, the server does not send its database, but rather, perhaps, some HTML,
XML or JSON that represents some database records expressed, for instance, in Swahili and
encoded in UTF-8, depending on the details of the request and the server implementation.
• Manipulation of resources through these representations
• When a client holds a representation of a resource, including any metadata attached, it has enough
information to modify or delete the resource on the server, provided it has permission to do so.
• Self-descriptive messages
• Each message includes enough information to describe how to process the message. For example,
which parser to invoke may be specified by an Internet media type (previously known as a MIME
type). Responses also explicitly indicate their cacheability.[1]
• Hypermedia as the engine of application state (aka HATEOAS)
• Clients make state transitions only through actions that are dynamically identified within
hypermedia by the server (e.g., by hyperlinks within hypertext). Except for simple fixed entry
points to the application, a client does not assume that any particular action is available for any
particular resources beyond those described in representations previously received from the
server.
32
37. in one stentence
• REST is everywhere. It is the part of the web
that makes it work well. If you want to build
distributed applications that can scale like
the web, be resilient to change like the web
and promote re-use as the web has done,
then follow the same rules they did when
building web browsers.
• http://stackoverflow.com/questions/1368014/
why-do-we-need-restful-web-services
37
38. Good Practices
• Map your API model to the way your
data is consumed, not your data/object
model.
• Meaningful error messages help a lot.
• Providing solid API documentation
reduces need for external help.
• Use an appropriate security APIs.
38
39. bad practices
• Chatty APIs suck.
• Returning HTML in response.
• Failing to realize that a 4xx error means I
messed up and a 5xx means you messed
up
• Side-effects to 500 errors are evil.
• http://broadcast.oreilly.com/2011/06/the-
39
41. JAX-RS
• JSR 311: JAX-RS:The Java API for RESTful Web Services
• Java EE 6 JSR-311 JSR-311
Java
REST
• JSR 339: JAX-RS 2.0
• Java EE 7 with JAX-RS 2.0 brings several useful features,
which further simplify development and lead to the
creation of even more-sophisticated, but lean, Java SE/EE
RESTful applications.
41