This document discusses REST (Representational State Transfer) and resource-oriented architectures. It provides examples of designing RESTful APIs and services using common REST constraints like URIs to identify resources, HTTP methods to manipulate resources, and resource representations. The key aspects covered are modeling the domain as resources, designing URIs, exposing a uniform interface, designing representations, and common interaction flows and error conditions.
Scott Davis presented on Resource-Oriented Architecture (ROA) and REST on August 17th at IASA Denver.
Google quietly deprecated their SOAP search API at the end of 2006. While this doesn't mean that you should abandon SOAP, it does reflect a growing trend towards simpler dialects of web services. Google joins a number of popular websites (Yahoo!, Amazon, eBay, and others) that offer all of the benefits of web services without all of the complexity of SOAP.
In this talk, we look at the semantic differences between a Service-Oriented Architecture and a Resource-Oriented Architecture. We contrast RPC-centric interfaces with object-oriented interfaces. We discuss HTTP-RPC services that call themselves RESTful, and compare them to fully RESTful web services that leverage HTTP verbs like GET, POST, PUT, and DELETE. We look at RESTful implementations using Java Servlets and exploit Grails' native REST support.
To view recording of this webinar please use below URL:
http://wso2.com/library/webinars/2015/09/resource-oriented-architecture/
Any given business, organization or entity is built with resources. It can be human capital, digital assets, services or products among other things. These activities often interact with each other creating a value network. A good example of this is when human resources interact with digital assets to perform a service. We as computer scientists, have been trying to simplify this interaction flow for quite some time.
The field of distributed systems and semantic web are dedicated to solving problems in this domain. RESTful services and the ecosystem around it have now simplified this interaction to a great level. Being able to interact with a resource with basic actions in a secure manner is a great achievement.
This webinar will discuss
The of history of ROA
Its current landscape
ROA and microservices
New development around the architecture pattern
The glory of REST in Java: Spring HATEOAS, RAML, Temenos IRISGeert Pante
-Introduction to REST and REST Maturity
-Spring HATEOAS
-RAML: RESTful API Modeling Language
-IRIS: Temenos Interaction, Reporting & Information Services
Les Hazlewood, Stormpath co-founder and CTO and the Apache Shiro PMC Chair demonstrates how to design a beautiful REST + JSON API. Includes the principles of RESTful design, how REST differs from XML, tips for increasing adoption of your API, and security concerns.
Presentation video: https://www.youtube.com/watch?v=5WXYw4J4QOU
More info: http://www.stormpath.com/blog/designing-rest-json-apis
Further reading: http://www.stormpath.com/blog
Sign up for Stormpath: https://api.stormpath.com/register
Stormpath is a user management and authentication service for developers. By offloading user management and authentication to Stormpath, developers can bring applications to market faster, reduce development costs, and protect their users. Easy and secure, the flexible cloud service can manage millions of users with a scalable pricing model.
Representational State Transfer (REST) and HATEOASGuy K. Kloss
Lecture from Auckland University of Technology in the Service-Oriented Architecture for the Master's course in Service-Oriented Computing (semester 2, 2013)
Overview of REST web service concepts (Representational State Transfer).
REST is a radically different approach for web services compared to the combo SOAP/WSDL.
REST defines an architectural style for web applications and web services.
REST makes heavy use of the underlying HTTP protocol.
REST itself is not a protocol but defines architectural principles based on the concept of addressable resources and a uniform access to these resources based on the well-known HTTP-methods GET, POST, PUT and DELETE.
The state of a client (web service consumer) is controlled by the REST web service through connected links between resources (resource oriented architecture). The client state however is stored on the client itself thus greatly increasing scalability of REST-based architectures.
The REST paradigm has mostly superseded SOAP / WSDL type web services in many enterprise applications. This is largely owed to the fact that the underlying HTTP protocol is well understood and proved its scalability in the WWW.
Scott Davis presented on Resource-Oriented Architecture (ROA) and REST on August 17th at IASA Denver.
Google quietly deprecated their SOAP search API at the end of 2006. While this doesn't mean that you should abandon SOAP, it does reflect a growing trend towards simpler dialects of web services. Google joins a number of popular websites (Yahoo!, Amazon, eBay, and others) that offer all of the benefits of web services without all of the complexity of SOAP.
In this talk, we look at the semantic differences between a Service-Oriented Architecture and a Resource-Oriented Architecture. We contrast RPC-centric interfaces with object-oriented interfaces. We discuss HTTP-RPC services that call themselves RESTful, and compare them to fully RESTful web services that leverage HTTP verbs like GET, POST, PUT, and DELETE. We look at RESTful implementations using Java Servlets and exploit Grails' native REST support.
To view recording of this webinar please use below URL:
http://wso2.com/library/webinars/2015/09/resource-oriented-architecture/
Any given business, organization or entity is built with resources. It can be human capital, digital assets, services or products among other things. These activities often interact with each other creating a value network. A good example of this is when human resources interact with digital assets to perform a service. We as computer scientists, have been trying to simplify this interaction flow for quite some time.
The field of distributed systems and semantic web are dedicated to solving problems in this domain. RESTful services and the ecosystem around it have now simplified this interaction to a great level. Being able to interact with a resource with basic actions in a secure manner is a great achievement.
This webinar will discuss
The of history of ROA
Its current landscape
ROA and microservices
New development around the architecture pattern
The glory of REST in Java: Spring HATEOAS, RAML, Temenos IRISGeert Pante
-Introduction to REST and REST Maturity
-Spring HATEOAS
-RAML: RESTful API Modeling Language
-IRIS: Temenos Interaction, Reporting & Information Services
Les Hazlewood, Stormpath co-founder and CTO and the Apache Shiro PMC Chair demonstrates how to design a beautiful REST + JSON API. Includes the principles of RESTful design, how REST differs from XML, tips for increasing adoption of your API, and security concerns.
Presentation video: https://www.youtube.com/watch?v=5WXYw4J4QOU
More info: http://www.stormpath.com/blog/designing-rest-json-apis
Further reading: http://www.stormpath.com/blog
Sign up for Stormpath: https://api.stormpath.com/register
Stormpath is a user management and authentication service for developers. By offloading user management and authentication to Stormpath, developers can bring applications to market faster, reduce development costs, and protect their users. Easy and secure, the flexible cloud service can manage millions of users with a scalable pricing model.
Representational State Transfer (REST) and HATEOASGuy K. Kloss
Lecture from Auckland University of Technology in the Service-Oriented Architecture for the Master's course in Service-Oriented Computing (semester 2, 2013)
Overview of REST web service concepts (Representational State Transfer).
REST is a radically different approach for web services compared to the combo SOAP/WSDL.
REST defines an architectural style for web applications and web services.
REST makes heavy use of the underlying HTTP protocol.
REST itself is not a protocol but defines architectural principles based on the concept of addressable resources and a uniform access to these resources based on the well-known HTTP-methods GET, POST, PUT and DELETE.
The state of a client (web service consumer) is controlled by the REST web service through connected links between resources (resource oriented architecture). The client state however is stored on the client itself thus greatly increasing scalability of REST-based architectures.
The REST paradigm has mostly superseded SOAP / WSDL type web services in many enterprise applications. This is largely owed to the fact that the underlying HTTP protocol is well understood and proved its scalability in the WWW.
This slide show is from my presentation on what JSON and REST are. It aims to provide a number of talking points by comparing apples and oranges (JSON vs. XML and REST vs. web services).
RESTful Architecture is effectively an implementation of Resource-Oriented architecture (ROA). ROA - is a good fit for Service oriented Architecture (SOA) implementation. Check out KickStartPros approach on RESTful API Design.
* REST = REpresentational State Transfer
* REST is Resource Based Representation. REST identifies things by JSON or XML & URIs.
* REST behavior/actions are identified by HTTP methods (GET, POST, PUT, DELETE).
* Using Uniform Interface Architecture with REST you can decouple Client (like Browser/Android App/iOS App) and Server.
* REST using Layered System and Cacheable Architecture gives better performance.
The Internet is full of Web Services, everyday more and more. Some services offer API (application programming interface) that developers use to build new applications (mash-ups). One of the most known and used technology for the machine-to-machine communication is SOAP (Simple Object Access Protocol) but in the last years we can use another paradigm, ReST (Representational State Transfer). How does it work?
An introduction to REST and RESTful web services.
You can take the course below to learn about REST & RESTful web services.
https://www.udemy.com/building-php-restful-web-services/
Presentation sur la contrainte d'architecture HATEOAS et comment le framework Spring nous facilite son implementation.
Source code : https://github.com/YoannBuch/simple-spring-restbucks
Fait par l'equipe de http://findtheflow.io, un outil qui permet d'analyser et visualiser des executions d'applications Java.
This session will provide attendees with hands-on experience and in-depth knowledge of using Node.js as a runtime environment and Express.js as a web framework to build scalable and fast backend systems. Additionally, attendees will learn about Passport.js, a popular authentication middleware for Node.js, and how to use Prisma ORM to handle database operations in a type-safe and efficient manner.
The session will be conducted by experienced developers who have worked with these technologies and will be able to provide valuable insights and best practices. The session will be interactive and include plenty of opportunities for attendees to ask questions and work on real-world projects.
This slide show is from my presentation on what JSON and REST are. It aims to provide a number of talking points by comparing apples and oranges (JSON vs. XML and REST vs. web services).
RESTful Architecture is effectively an implementation of Resource-Oriented architecture (ROA). ROA - is a good fit for Service oriented Architecture (SOA) implementation. Check out KickStartPros approach on RESTful API Design.
* REST = REpresentational State Transfer
* REST is Resource Based Representation. REST identifies things by JSON or XML & URIs.
* REST behavior/actions are identified by HTTP methods (GET, POST, PUT, DELETE).
* Using Uniform Interface Architecture with REST you can decouple Client (like Browser/Android App/iOS App) and Server.
* REST using Layered System and Cacheable Architecture gives better performance.
The Internet is full of Web Services, everyday more and more. Some services offer API (application programming interface) that developers use to build new applications (mash-ups). One of the most known and used technology for the machine-to-machine communication is SOAP (Simple Object Access Protocol) but in the last years we can use another paradigm, ReST (Representational State Transfer). How does it work?
An introduction to REST and RESTful web services.
You can take the course below to learn about REST & RESTful web services.
https://www.udemy.com/building-php-restful-web-services/
Presentation sur la contrainte d'architecture HATEOAS et comment le framework Spring nous facilite son implementation.
Source code : https://github.com/YoannBuch/simple-spring-restbucks
Fait par l'equipe de http://findtheflow.io, un outil qui permet d'analyser et visualiser des executions d'applications Java.
This session will provide attendees with hands-on experience and in-depth knowledge of using Node.js as a runtime environment and Express.js as a web framework to build scalable and fast backend systems. Additionally, attendees will learn about Passport.js, a popular authentication middleware for Node.js, and how to use Prisma ORM to handle database operations in a type-safe and efficient manner.
The session will be conducted by experienced developers who have worked with these technologies and will be able to provide valuable insights and best practices. The session will be interactive and include plenty of opportunities for attendees to ask questions and work on real-world projects.
Primary focus of this presentation is on the hypermedia as the engine of application state (HATEOAS) and how HTTP APIs may benefit from it. Provides sneak peek into HAL media type & gives an overview of hypermedia support in Java tools (JAX-RS / HalBuilder and Spring HATEOAS) along with practical suggestions for server-side design of hypermedia API. Also includes quick overview of Richardson Maturity Model based on a set of examples, current API trends.
Slides from the May 20th workshop at the Seattle Node.js Meetup presented by Shubhra Kar titled: "Develop, Deploy, Monitor and Hyper-scale REST APIs Built in Node.js"
What went wrong for my clients in the past 6 years trying to implement Microservice Architectures? This is a retrospective, a list of things we must to avoid to gainable with this kind of software architecture.
Not so many years have passed since we started programming computers and even less since programming computers has been recognised as a profession. Even still, so many things depend on the quality of our work. What does it mean to be professional? What are we expected to do? Are we up for the task? I will talk about my journey of becoming the programmer of my dreams, the obstacles I've faced and the strategies that I've applied to overcome them
URLs are not meant to be given to the clients but they should be discovered through the interaction with the server inside the representation of the resources. But thinking about URLs it's like thinking about names and relations between your domain resources. Creating a good URL grammar helps a good resource design. A good resource design is more stable and more extensible.
Node.js is one of those technologies that should not exist. Definitely, theoretically, is not supposed to have this kind of success. But like the bumblebee he don't know he can't and so it goes :-)
3. REST is not
a Protocol
an Architecture
a Software
a Standard
a fancy name for Web Services
a Buzzword
4. Representational
State
Transfer
Roy T. Fielding
“Architectural Styles and the Design of Network-based Software Architectures”
Ph.D dissertation, 2000
5. REST is
a Software Architecture Style
a set of Constraints on Component
Interaction that, when obeyed, cause
the resulting Architecture to have
certain properties
Roy T. Fielding http://roy.gbiv.com/untangled/2008/on-software-architecture
7. prediction for 2009
“Roy Fielding will officially disown most of the
RESTful authors and software packages
available. Nobody will care, or worse, somebody
looking to make a name for themselves will
proclaim that “Roy doesn't really understand
REST”, and they'll be right: Roy doesn't
understand what they consider to be REST”
http://dotnet.dzone.com/articles/ted-neward-2009-predictions-20
8. why?
“... the motivation for developing REST was to
create an architectural model for how the Web
should work, such that it could serve as the
guiding framework for the Web protocol
standards”
http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm
43. GET /position/wqd3,wkd2,bke8.gif HTTP/1.1
Accept: image/gif
HTTP/1.1 406 Not Acceptable
or more friendly
HTTP/1.1 300 Multiple Choices
Content-Type: application/xml
n
<choices><content type=”image/png” uri=”...”>
46. GET /game/42 HTTP/1.1
Accept: application/xhtml+xml
<html>
... <a rel=”owner” href=”/player/1001”>...</a> ...
<ul class=”moves”>
<li><image src=”/position/initial.png”/></li>
</ul>
</html>
Semantic Web is not a dream
47. Tim Berners-Lee
on Linked Data
“... almost 20 years ago I wanted
to reframe the way we use
informations ... I invented the
Word Wide Web ... now is time
for a new reframing...”
Tim Berners-Lee @ http://linkeddata.org
48. expected behavior of the web
1. Use URIs as names for things
2. Use HTTP URIs so that people
can look up those names
3. When someone looks up a URI,
provide useful information
4. Include links to other URIs, so
that they can discover more things
49. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic dXN1cm5hbWU6cG...
n
<game>
<player>...</player>
<moves>
<position>/position/initial</position>
<position color=”white”>
/position/wra1,wna2,...,wpd4,...
</position>
</moves>
</game>
... from and to the Client
51. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic dXN1...
n
<game>
<player>...</player>
<moves>
<position>/position/initial</position>
<position color=”white”>
/position/wra1,wna2,...,wpd4,...
</position>
</moves>
</game>
white Player make first move
52. HTTP/1.1 201 Created
Location: /game/42/position/2
Response to the white Player
GET /game/42/position/2
HTTP/1.1 301 Moved Permanently
Location: /position/wra1,wna2,...,wpd4,...
53. GET /game/42 HTTP/1.1
Authorization: Basic dXN1...
n
<game>
<player>...</player>
<moves>...</player>
</game>
GET /game/42 HTTP/1.1
Authorization: Basic aYR5...
n
<game>
<player>...</player>
<moves>...</player>
</game>
both Players must GET
the game Representation
54. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic aYR5...
n
<game>
<player>...</player>
<moves>
<position>/position/initial</position>
<position>/position/wra1,wna2,...,wpd4,...</position>
<position color=”black”>
/position/wra1,wna2,...,bpd5,...
</position>
</moves>
</game>
black Player can make next move
55. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic aYR5...
n
...
what if black Player try to resend?
HTTP/1.1 409 Conflict
the game Representation is
out of date
56. POST /game/42 HTTP/1.1
Content-Type: application/vnd.dharma.chess
Authorization: Basic aYR5...
n
...
what if black Player try to move again?
HTTP/1.1 403 Forbidden
the black Player should wait
for the white Player to move
57. POST /position/wqd3,wkd1,bke8 HTTP/1.1
n
move = d3-e8
what if we try to make a wrong move?
HTTP/1.1 404 Not Found
Business Rules could be easily
expressed through the Resource's
Behavior
62. FAQ: cool URIs
are RESTful?
OpenSocial
/people/{guid}/@all
Collection of all people connected to user {guid}
http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol.html
63. FAQ: REST is
stateless?
Statelessness says that
all possible states of the server
are also Resources
(Resource State)
64. FAQ: REST is
stateless?
Statelessness says that
each message contains
all the informations necessary
to understand the Request
(Application State)