Restful imaginarium


Published on

In this RESTful Imaginarium you will learn about about the core concepts of REST demonstrated through three leading RESTful web service frameworks: RESTlet, Spring MVC and NetKernel. During this daydream you will learn about the fallacies of URL parameters, the debate of PUT vs. POST and the power of HATEOAS.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Restful imaginarium

  1. 1. RESTful  Imaginarium   Jeremy  Deane     h5p://  
  2. 2. Agenda      Representa?onal  State  Transfer  (REST)        REST  Conceptual  Model      Universal  Resource  Indicators      Representa?ons      State  Transfer      HTTP  Protocol      Service  Design  Pa5erns        REST  Framework  Examples  (Restlet,  Jersey,  Spring  MVC,  NetKernel)  
  3. 3. Why  REST?   Simple  Integra.on   REST  is  simple.   Standards-­‐based   REST  is  based  on  a  small   set  of  widely-­‐accepted   standards  such  as  HTTP   URI,  and  XML   REST  requires  far  fewer   development  steps,   toolkits  and  execu?on   engines  than  SOAP   Fewer  requirements  
  4. 4. Representa?onal  State  Transfer  (REST)     Web  Principles   URI   HTTP  Methods   REST  is  an  architectural  style  based  on  the  principles  of  the  web   A  service  provides  access  to  a  resource,  iden?fied  by  a   Universal  Resource  Indicator  (URI),  over  HTTP   HTTP  methods  (e.g.  GET,  PUT,  POST,  and  DELETE)  define  a   uniform  interface   Consumer  and  provider  exchange  immutable  representa?ons   of  a  resource  that  may  itself  contain  links  to  other  resources   Resource   Representa?ons   «execu?on  environment»   Web  Applica.on   «execu?on  environment»   Web  Applica.on   Consumer   Service   Provider   URI   HTTP  GET  Request   HTTP  Response:  200  (ok)   XML   Representa?on  
  5. 5. REST  Conceptual  Model   Execu?on   Context   Service   Resource   Resource   Representa?on   Resource   Provider   Resource   Iden?fier   Policies  and   Contracts   Service   Consumer   Real-­‐World   Effect   part  of   use   represents   seeks   part  of   provide  access  to   returns   constrains   limits  use  of   hosts   iden?fies   OASIS  SOA   Concepts   REST   Concepts   Key  
  6. 6. Examples: Building, Room, floor Resources  &  Universal  Resource  Iden?fiers  (URI)   A  resource  is  an  abstract  set  of  data   /building/{building-id} /building/{building-id}/room/{room-id} A  resource  representa?on  is  iden?fied  by  a  URI   A  URI  does  NOT  contain  verbs  or  resource  iden?fying  parameters   Incorrect   /building/{building-id}?action=update Correct   /building/{building-id}/room/{room-id} Incorrect   /building/{building-id}/delete/room/{room-id}
  7. 7. Representa?ons   Representa.on   A  representa?on  is  an   immutable  physical   snapshot  of  a  resource   A  representa?on  is  self-­‐ descrip?ve  and  stateless   The  most  common   resource  representa?ons   are  XML  and  JSON   A  representa?on  may   contain  links  to  other   resources  (hypermedia)  
  8. 8. State  Transfer   Applica?on  State   State  transfer  refers  to  the  Applica5on  state   between  a  consumer  and  provider.  It  does   NOT  refer  to  the  state  of  a  given  resource.   Maintenance   Applica5on  state  is  maintained  by  the   consumer  while  Resource  state  is   maintained  by  the  provider.   No  side  effects   A  request  for  a  resource  should  not  change   the  state  of  a  resource  (no  side  effects).   Idempotent   Duplicate  requests  to  create,  update,  or   delete  a  resource  should  not  result  in  a   change  in  Resource  state.  
  9. 9. HTTP  Uniform  Interface:  Structure  &  Transport  Protocol   Request  and  response   messages  are  comprised   of  a  command,  headers,   and  a  body   HTTP  is  stateless  request-­‐response  applica?on  protocol   Requests  can  be   authen?cated  using     HTTP  Basic  Authen?ca?on   or  Client  Side  Cer?ficates   The  transport  layer  is   secured  using  Secure   Sockets  Layer  (SSL)  and  the   message  body  is  secured   using  encryp?on  and   digital  signatures  
  10. 10. HTTP  Uniform  Interface:  Methods   Ac?on   Result   PUT /building/{building-id} Creates a resource GET /building/{building-id} Retrieves a resource representation POST /building/{building-id} Updates a resource DELETE /building/{building-id} Deletes a resource Ac?on   Result   POST /building/ Creates a resource GET /building/{building-id} Retrieves a resource representation PUT/building/{building-id} Updates a resource DELETE /building/{building-id} Deletes a resource
  11. 11. HTTP  Uniform  Interface:  Content  Nego?a?on   URI  Content  ID   URI  Content  Extensions   Accept  Headers  –  Media  Types   /building/{building-id}/room/pdf/{room-id} /building/{building-id}/room/{room-id}.xml Accept Headers = application/xml
  12. 12. Securing  RESTful  Endpoints  -­‐  assurance  of   consumer  iden?ty   • HTTP  Basic  Authen?ca?on  (with  SSL)  or   client  side  cer?ficate   Authoriza.on  -­‐  unauthorized   resource  access  is  prevented   • A  privilege  is  comprised  of  a  rela?ve  URI   and  an  ac?on  (C.R.U.D)   • Accounts  are  associated  with  privileges  or   roles  (sets  of  privileges)  –  state  change  of  a   resource  is  logged   Confiden.ality  -­‐  securing  resource   representa?ons   Create,  Update  or  Delete  ac?ons  are   audited   Encryp?on  of  resource  representa?ons  
  13. 13. SOAP  vs.  RESTful  Web  Service   HTTP  Request  or  Response   HTTP  Body   HTTP  HEADERS   XML  Document   HTTP  Request  or  Response   HTTP  Body   HTTP  HEADERS   SOAP  Envelope   SOAP  Body   XML  Document   SOAP  HEADERS  
  14. 14. SOAP  vs.  RESTful  Web  Services   REST-­‐XML   SOAP-­‐XML   • Simplicity   • Proven  architectural  style   (Web)   • Fewer  development  steps,   toolkits  and  execu?on   engines   • Transport  Independence   • Intelligent  messages   • Transport  Independence   • Message  Intelligence   • Complexity   • Ever-­‐changing,  vendor-­‐driven   specifica?ons   • Requires  complex  tools  and   frameworks   Advantage   Disadvantage  
  15. 15. (Web)  Service  Design  Pa5erns   h5p://  
  16. 16. Jersey  Overview   Open  source   framework   Web  services   Jersey  is  a  reference  implementa?on  of  JAX-­‐RS  (JSR  311)   Jersey  web  services  are  created  by  configuring  a  Servlet  in   the  web.xml  and  annota?ng  classes   The  Servlet  delegates  to  resources  in  the  same  way  that  a   Struts  controller  delegates  to  ac?ons   Annota?on  based  URI  mappings  and  templates   Delega.on   URI   Guar  
  17. 17. Restlet  Overview   Open  source   framework   Web  services   Restlet  is  a  lightweight  open  source  framework  for   implemen?ng  REST  concepts  in  Java   Restlet  web  services  are  created  by  configuring  the  web.xml   and  implemen?ng  abstract  classes   A  router  delegates  to  resources  in  the  same  way  that  a   Struts  controller  delegates  to  ac?ons   The  router  maps  external  requests  to  resources  based  on  a   Universal  Resource  Indicator  (URI)   A  guard  is  also  associated  to  a  router  and  provides  a   mechanism  for  client  authen?ca?on.   Delega.on   URI   Guard  
  18. 18. Spring  MVC  Overview   Open  source   framework   REST  WS   Spring  MVC  is  a  key  part  of  the  Spring  Framework   Spring  MVC  provides  advanced  features  for  implemen?ng   RESTful  web  services  such  as  URI  Templates   Spring  MVC  provides  advanced  features  for  implemen?ng   RESTful  web  services  such  as  URI  Templates   A  Dispatcher  delegates  a  request  to  Controller  based  on   advice  from  a  Mapping  Handler.  The  Dispatcher  then   consults  a  View  Resolver  before  returning  a  View  (response)   Dependency   Injec.on   Components   Guard  
  19. 19. NetKernel  Overview   ROC     plaPorm   Netkernel  is  a  Resource-­‐Oriented   Compu?ng  (ROC)  plahorm  that  runs  within   a  Java  Virtual  Machine  (JVM)   Transports   Transports  are  used  to   • Capture  external  request  or  events   • Map  request  or  event  data  to  a  logical   address  (URI)  and  ac?on  (C.R.U.D)   • Issue  sub-­‐request  to  a  RESTful   Microkernel   RESTful   microkernel   The  RESTful  microkernel   • Resolves  requests  to  the  address  space  to   physical  code   • Schedules  request  to  run  on  available   core  allowing  processing  to  scale  linearly   NetKernel  Middleware   Server   Transports   HTTP,  JMS,  FTP   Logical  Address  Space   URI   RESTful   Microkernel   Physical  Code   (Java,  Ruby,  Scala)  
  20. 20. Ques?ons  &  Feedback   My  Contact   informa.on:   Jeremy  Deane     Director  of  Sojware  Architecture   NaviNet   h5p://   h5ps://­‐spring-­‐auditor   h5ps://­‐jersey-­‐auditor   h5ps://­‐restlet-­‐auditor   h5ps://­‐netkernel-­‐auditor