REST presentation
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

REST presentation

on

  • 2,189 views

(update) introduction to REST

(update) introduction to REST

Statistics

Views

Total Views
2,189
Views on SlideShare
2,173
Embed Views
16

Actions

Likes
3
Downloads
47
Comments
0

3 Embeds 16

http://www.linkedin.com 11
https://www.linkedin.com 3
https://twitter.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • I am not going to talk about the “Code On Demand” since it is optional (also easy to understand – think javascript)
  • RR is the precursor for cacheability (!)
  • trades-off efficiency of interaction for easier of integration and better independent evolvability of resources
  • In a nutshell document-centric means that the message contains enough information to represent a complete unit of work. RPC calls tend to be geared toward sending just the parameters needed to perform the action and have some stateful expectations from the service. Document-centric message, on the other hand, don’t make these assumptions, having a complete unit-of-work, means that the service has enough information or context in the message to understand all the state it needs. This also means that document centric messages are usually more coarse grained compared with their RPC counterparts. Table 5.2 below demonstrates 3 ways document centric messages can contain more context. ContextExplanationHistoryThe message can contain the interaction up to this point - sort of like breadcrumbs in ht Hansel and Gretel tale. For instance in an Ordering scenario, if the first step was to get customer data and the current step is to set the order (each step can be with another service) the message would contain the customer information when it goes into the ordering service.Future The message can include the options the consumer can take to complete the interaction. Again, if we think about an ordering scenario, if the previous step was to reserve the order (see Reservation pattern in chapter 6), the return message can include the information needed to confirm the reservation.Complete Future Another way to provide context is for the message format to contain the complete details needed for the interaction. For the ordering example, this would mean that the message would have a skeleton to support all the order and related details and the parties involved will fill in the blanks as the interaction progresses.
  • (contrast this to objects that encapsulate them)
  • where you can actually find the thingor rather Representations of ite.g.in this case (www.uri.com.hk) representations of underwear fashion
  • HTTP defined a protocol (headers, verbs + response type etc.)GETPUTPOSTDELETEOPTIONSHEAD(TRACE –loop back the request as it is received by the server, can be a security hazard) CONNECT – defined in the spec as reserved)
  • e.g. Waka by Roy Fielding with things likeRender ~ GetMonitor – subscribe to changes
  • In UPDATE you can send only the “diff” using put (and the document centric messaging) you can only replace
  • Can be used to check if state changed since last time if retrieving the body is a heavy operation
  • e.g. when you call the root URI it will let you know
  • Easier integration It isn’t that integration magically happen because of the uniform interface – but it is easier for humans to understandIn RESTful HTTP integration is even easier because HTTP is ubiquitous so it is also easy to integrate cross-platformEasy to expose services to UI esp. in the technologies we choseaNot without challenges e.g. – getting security right, getting URIs right
  • We already seen that
  • As mentioned REST trades-off efficiency for interoperability and integrationWhen you do need efficiency then REST is wrongIt was also designed for Hypermedia systems (i.e. Web) if your solutions can’t support that, than it is wrong.If you have to integrate existing stuff that is not RESTful than it is wrongEtc.
  • A lot of people don’t understand REST and can create havoc just like in RPC based systeme.g. translating every verb into a URI:http://www.example.com/DoActionThe fallacies of distributed computing still matter REST does encourage some of the recommended practices (e.g. statelessness of communications, document centric messages, use of cache etc.)
  • It builds on simple concepts But you should be mindful to get it rightDefine the correct ResourcesUse cache (e.g. ETAG and Last-Modified in HTTP) Parse data in and out etc

REST presentation Presentation Transcript

  • 1. Give it a REST already Arnon Rotem-Gal-Oz http://arnon.me
  • 2. SomeTheory
  • 3. Making sense of the terminology soup Architectural Styles Architectural Patterns Design Patterns Architecture Design Code/Detailed Design
  • 4. SOA vs. RESTDistributed Pipes and Layered Client Replicated Uniform Virtual Agents Filters System Server Repository Interface Machine Stateless Code On Cacheable Comm. Demand SOA REST
  • 5. REST = "Representation State Transfer" Categorization App Categorization (Resource) Data Management (Resource)
  • 6. Layers should have some constraints on communications Layer? Layer? Layer? Layer?
  • 7. Layers should have some constraints on communications Layer layer Component Layer Component
  • 8. Layers should have some constraints on communications Layer Component Layer Component Layer
  • 9. Client/Server Client Server Request Capabilities (services)Requests initiator Reply
  • 10. Replicated Repository is copy copy copy about having copy copy copymore than onecopy providing copy copy copy the same service looks like one copy better performance and latency
  • 11. The uniform interface
  • 12. Document Centricmessages providethe client with the needed state and allow stateless communications
  • 13. REST also externalize state transitions (HATEOAS) Current Link to Representation customer E.g. Order Link to Link to Product 2 product 1
  • 14. Example – Resource Manager root 1 2 3 Abcde/ Sessions/ Efgh/ / Resources/ Dispatchers/ Xyz/
  • 15. http://devrig:52141/RM/Sessions/abc/• ATOMPUB – Session details • URI (ID) • State (start/end/status etc.) • Resources – Knows status – URI for the Resource representation on the RM – URI for the Resource itself
  • 16. Use IDs that are linkse.g. a
  • 17. HTTP is the most common REST implementation
  • 18. But you can create others Waka canoe
  • 19. GET = query/read a resource for a representation
  • 20. PUT = create withID set by the client / replace
  • 21. POST = Create a subordinate resource with ID set by server / update
  • 22. DELETE= remove the URI (most likely delete the resource)
  • 23. HEAD = GET but only retrieves metadata (headers)
  • 24. OPTIONS – Thecurrently available verbs / requirements for communication
  • 25. WhyREST?
  • 26. (original) Categories REST APICategoriesPOST – create new categoryGET – List categories / search for category Tasks POST – run discovery GET – list running categoriezations <Task Id> GET– check progress/status of running categorization / / DELETE– abort categorization <Cat Id> GET– Get Category definition PUT– update category (state or definition) DELETE – remove categoryInteractionsGET – search interactionsPOST – Create interactions (bulk) <Int Id> GET– Retrieve Interactions PUT– Create /Update Interaction <Seg Id> GET– Retrieve segment PUT– Create /Update segment (e.g. words from audio-analysis)
  • 27. Technology Mapping
  • 28. Jax-RS
  • 29. Spring HATEOAS
  • 30. Common REST misconceptions
  • 31. REST = CRUD
  • 32. REST is the ultimate architecture
  • 33. REST = HTTP
  • 34. REST will automagically make youwrite perfect distributed systems
  • 35. REST is Simpler