Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

REST4DEV

No description
by

Dong Liu

on 28 June 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of REST4DEV

REST
Representational State Transfer
World Wide Web
HTTP
RPC
Architectural style
R. Fielding
RESTful
Architectural Style
Software architecture = {Elements, Constraints, Rationale}
Christopher Alexander. The Timeless Way of Building. Oxford University Press, New York, 1979.
Dewayne E. Perry and Alexander L. Wolf. Foundations for the study of software architecture. SIGSOFT Softw. Eng. Notes, 17(4):40--52, 1992.
style
:
architecture

patten
:
design
Elements: data, process, connector
Constraints: configuring and organizing elements
Rationale: reasons behind the decisions
Define a style
Problem domain
Consequences
Common characteristics
of design problems
Solution
Element types and roles
Common constrains
Common Rationale
Structure
Behavior
Implementation
address
bring
Representational State Transfer
Problem domain
Consequences
distributed hypermedia system
network-based application
Solution
address
bring
Design-by-buzzword is a common occurrence. At least some of this behavior within the software industry is due to a lack of understanding of why a given set of architectural constraints is useful.
Roy Fielding
Architectural Styles and the Design
of Network-based Software Architectures
An introduction to REST
Dong Liu
FRIB, MSU
Uniform interface
Uniform identifiers for important resources
Same access methods for resources
Manipulate resources by exchanging representations
Representations are self-descriptive messages
Hypermedia as the engine of application state (
HATEOAS
)
CORBA
RMI
XML-RPC
SOAP
WS-*
Firewall
"REST" vs RPC/SOAP
Richardson Maturity Model
http://martinfowler.com/articles/richardsonMaturityModel.html
1
0
2
3
Web constraints and practices
http://www.w3.org/TR/2004/REC-webarch-20041215/
Provide URIs as identifiers for resources
Assign distinct URIs to distinct resources
Reuse an existing URI scheme
NOT ignore message metadata
Provide representations of the identified resource consistently and predictably
Provide ways to identify links to other resources, including to secondary resources (via fragment identifiers)
More Resources
Fielding's thesis
RESTful Web Services by Richardson and Ruby
RESTful Web APIs by Richardson, Amundsen, and Ruby
Restful Web Services Cookbook by Allamaraju
Yahoo REST discuss group (not active recently)
RESTful API languages
HAL (http://stateless.co/hal_specification.html)
JSON API (http://jsonapi.org/)
More in HTTP specification RFC 2616
Case study
Scenario
A web application for cable management
Request/approval/procurement/installation workflow
Paradigm
Test driven development
Refactoring
Resources
Identifiers
Methods
Representations
Application/test
Round 1
Cables
Cables
Requests
/requests/
/requests/:id
How about others?
/request
/cablerequest
/requests/
GET
POST
POST
GET
PUT
DELETE
Create
Retrieve
Update
Delete
!==
the list of requests
Create a new request
GET /requests/
200
request #1 link
request #2 link
...
more requests link
Accept: text/html, ...
GET /requests/
Accept: application/json
GET /requests/
How about json?
/requests/:id
Javascript
API
Other representations
GET /reqeusts/json
GET /reqeusts.json
Request:
Response:
Representations
Methods
Application/test
GET: retrieve the request
PUT: update the request
Delete

create a resource: POST or PUT
POST /resources/

representation of the new resource

201 Created
Location: http://host:port/reources/resource_id

202 Accepted

Check /resources/ later
PUT /resources/resource_id

representation of the new resource

201 Created
Location: http://host/reources/resource_id

409 Conflict
/reources/resource_id was already there and cannot be modified

204 No Content

301 Moved Permanently
Location: http://host/reources/other_resource_id
/requests
to slash or not to slash
Traditionally, slash represents the directory hierarchy in a file system
Similarly, url/ implies a collection of resources, and url implies an entity
When a full URL is derived from a relative URL, whether the base URL is ended with a slash is critical, see http://www.w3.org/TR/WD-html40-970708/htmlweb.html#relative-urls
If you want to forward the clients to the right URL if they add or miss slash, try a tool like https://github.com/ericf/express-slash
Content negotiation was not considered practical
HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out.
...
Many people seem to use HTTP content negotiation as a motivation for adding 'version' parameters to MIME types or registering new MIME types, with the hopes that the MIME types or parameters would be useful in HTTP content negotiation, and we should warn them that it isn't really productive to do so. That's why it might be useful advice to add to the guidelines for registering MIME types, should those ever be updated.

See http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html
It is also not clear how the agent-driven content negotiation will work with caching
A proxy resource
A resource whose representation is retrieved from third-party API
A simple solution is
Is this RESTful
Test the resource with a popular browser
Not RESTful
Representation is not consistent with the host
Meta information of the third-party API can conflict with the host
Sensible meta information from the third-party API can leak
The status codes from the third-party API will confuse the clients
How about timeout?
...
A better solution
request({
url: 'http://third/party/service',
timeout: 30 * 1000,
...
}, function (err, response, resBody) {
if (err) {
return res.json(503, ...);
}
...
});
app.get('/proxy/resource', function (req, res) {
request.get('http://third/party/service').pipe(res);
})
Full transcript