Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Rest and Rails

4 274 vues

Publié le

Publié dans : Technologie
  • Soyez le premier à commenter

Rest and Rails

  1. 1. REST And rails<br />Chhorn Chamnap<br />YoolkMango<br />15 - July - 2010<br />
  2. 2. Agenda<br />REST Theory<br />RESTful Rails<br />Case Study<br />Authentication<br />References<br />
  3. 3. REST Theory<br />
  4. 4. REST Introduction<br />REST is a unifying theory for how “distributed hypermedia” systems are best organized and structured.<br />Lesson learnt from developers:<br />CRUD operations correspond to HTTP POST, GET, PUT, and DELETE.<br />Consistent, robust, and understandable.<br />Names identifies resources<br />
  5. 5. Resources<br />A resource is something with identity.<br />a row in adatabase, a physical object, an abstract concept, or a real-world event in progress<br />A resource has a URI. <br />Possible to have more than one???<br />Different representations of a resource vary based on their content types.<br />How does the server know which one to send?<br />URI extensions (/users/1.html,/users/1.xml)<br />Content negotiation (Accept-Language, Accept-Charset, Accept-Encoding, or Accept)<br />
  6. 6. Resources (example)<br />GET /orders/124 HTTP/1.1<br /> Host: www.example.com<br /> Accept: text/html, application/xhtml+xml, text/*, image/png, image/*, */*<br />
  7. 7. Embrace hyperlinks <br />Use hyperlinks to related resources. <br />Provide a reasonable quantity of information and link to further details. <br />
  8. 8. Statelessness<br />REST is stateless.<br />It presents scalibility.<br />Each request carries no state at lower or higher levels.<br />Resource state<br />the internal state that all non trivial resources carry, and it is essential to a web application.<br />Application state (session state)<br />the state of the cli-ent’s interaction with the server<br />keeping this state on the server violates REST principles as it breaks addressability.<br />
  9. 9. HTTP Verbs (HTTP Methods)<br />Verbs correspond to actions on resources.<br />GET<br />HEAD<br />POST<br />PUT<br />DELETE<br />
  10. 10. Safe Methods<br />Safe methods are used for retrieval.<br />never be to perform an update<br />All safe methods are idempotent.<br />
  11. 11. Idempotent Methods<br />GET, HEAD, PUT, and DELETE are idempotent methods.<br />The response (and resource state) is the same, no matter how many times thataction is performed.<br />
  12. 12. HTTP Status Codes<br />Success and failure should be inferred from the HTTP response status<br />not from an error message within the payload.<br />1xx: Informational<br />2xx: Success<br />3xx: Redirection<br />4xx: Client Error<br />5xx: Server Error<br />
  13. 13. GET Method<br />Transfers a representation of a resource to the client.<br />Read-only access to a resource.<br />The server must decide to perform an update based on a safe request.<br />
  14. 14. PUT Method<br />Updates a resource with the representation provided in the body.<br />If not exist before, the request creates a new one.<br />
  15. 15. DELETE Method<br />Deletes the resource identified by its URI.<br />Subsequent GET queries to the same URI should return a status code of 410 (Gone) or 404 (Not Found).<br />
  16. 16. POST Method<br />Neither safe nor idempotent<br />Two primary uses:<br />creation of new objects<br />annotation of existing objects<br />The URI of the POST is that of the object’s container or parent.<br />The Location header should point to the URI of the created resource<br />
  17. 17. RESTful Rails<br />
  18. 18. Resource-Based Named Routes<br />Encapsulates all of the Rails CRUD actions into one routing statement<br />map.resources :users<br />
  19. 19. Custom resource routes<br />create custom named routes either to the collection (the parent resource) or the members of the collection (the children).<br />map.resources :people, :collection => { :search => :get }, :member => { :deactivate => :post }<br />
  20. 20. Nested routes<br />map.resources :people do |person|<br /> person.resources :friends<br />end<br />/people/1/friends<br />/people/1/friends/2<br />map.resources :people do |person|<br /> person.resources :friends, :name_prefix => 'person_'<br />end<br />The name _prefix option adds a prefix to the generated routes.<br />person_friends_path and person_friend_path<br />
  21. 21. Nested routes (cont.)<br />map.resources :people<br />map.resources :friends,<br /> :name_prefix => 'person_',<br /> :path_prefix => '/people/:person_id‘<br />path_prefix option will add a prefix to the URIs that the route will recognize and generate.<br />
  22. 22. Singleton resource routes<br />Sometimes, there will be an entity that exists as a singleton.<br />map.resources :users do |user|<br /> user.resource :account<br />end<br />The resource name is still singular, but the inferred controller name is plural.<br />
  23. 23. ActionView Support<br />The link_to family of helpers can take a :method parameter to define the HTTP method.<br />generate hidden form field for the _method parameter for PUT and DELETE.<br /><%= link_to 'Delete', person_path(@person), :method => :delete %><br />
  24. 24. Content Types<br />Rails has introduced rich support for rendering different responses based on the content type the client wants, via the respond_to method.<br />respond_to do |format|<br /> format.html #format.html { render }<br /> format.xml { render :xml => @product }<br />end<br />respond_to :html, :xml<br />In config/initializers/mime_types.rb<br />Mime::Type.register "image/jpeg", :jpg, [], %w(jpeg)<br />
  25. 25. Content Types (cont.)<br />
  26. 26. Content Types (cont.)<br />
  27. 27. Resourceful session state<br />Alternative to holding session state on the server?<br />Nearly any problem REST developers face, the solution is to model it as a resource.<br />
  28. 28. Case Study<br />
  29. 29. Example<br />
  30. 30.
  31. 31.
  32. 32. Refactor<br />
  33. 33. Refactor (example)<br />
  34. 34. Refactor (example)<br />
  35. 35.
  36. 36. Authentication<br />
  37. 37. Authentication<br />Can we used cookies?<br />Yes, cookies can be used, but mainly for authentication.<br />How to authenticate users in a RESTful way via the browser and other clients?<br />
  38. 38. Authentication (cont.)<br />Use cookies/sessions to store information just for authentication.<br />Use HTTP Basic authentication for other server side clients.<br />For more secure, use secure http.<br />
  39. 39. Authentication (cont.)<br />
  40. 40. Authentication (cont.)<br />
  41. 41. References<br />Advanced Rails Recipes<br />OReilly Advanced Rails<br />Oreilly RESTful Web Services<br />http://ajaxpatterns.org/RESTful_Service<br />