Your SlideShare is downloading. ×
0
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Rest
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rest

175

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
175
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript

    • 1. Your data needs to bepromiscuousIf there’s any hope of ithooking up with the iPhone
    • 2. Your data needs to bepromiscuousIf there’s any hope of ithooking up with the iPhone
    • 3. API• The I means Interface• Necessary to interact with any application outside of a web site • Smart phone • Ajax
    • 4. BPEL SOAPRPC WSDL
    • 5. Facebook
    • 6. Twitter
    • 7. REST• Representational• State• Transfer
    • 8. Representing State• JSON• HTML• PDF• XML?
    • 9. XMLJames Clark: “My reaction to JSON is a combination of ‘Yay’ and ‘Sigh’. Its ‘Yay’, because for important use cases JSON is dramatically better than XML. In particular, JSON shines as a programming language- independent representation of typical programming language data structures. This is an incredibly important use case and it would be hard to overstate how appallingly bad XML is for this. The fundamental problem is the mismatch between programming language data structures and the XML element/attribute data model of elements.”
    • 10. Verbs• GET: Retrieve data• PUT: Replace data• POST: Add data• [PATCH]: Update data• DELETE: Remove data
    • 11. HTTP
    • 12. Collections• GET: List items in a collection• PUT: Replace a collection with new items • Functions as a PATCH in the real world• POST: Add an item to this collection • New or existing item• DELETE: Remove all items in this collection • There be danger
    • 13. Item• GET: Retrieve the representation of this item• PUT: Update the item with new values • Functions as PATCH in the real world• DELETE: Remove the item
    • 14. Uniformity• Relative to a base URL • A description of resources often placed here• Collections are identified by the type of object in the collection • http://baseurl/resource/• Items are identified by the type and ID of the item • http://baseurl/resource/12• Collections can be related to a specific item • http://bareurl/parent/12/resource
    • 15. Varied Representations• Requesting a return type may be done through resource URL • http://baseurl/resource/12.json • http://baseurl/resource/12.html• Requesting a return type may be done through Accept header • Accept: application/json
    • 16. Responses• Use HTTP error codes where appropriate• Standardize a method of measuring success• Standardize a method of returning errors • Add an error flag • State the main error message • State the error type • Allow data to be conveyed along with the error
    • 17. Blog• Uses many REST patterns• Collection of posts often at /blog/ • Object type used for lookup• Items usually at /blog/id• Items can be added to a category “collection” of posts
    • 18. Caching• GET requests can be cached by browsers • Should never alter state • Several headers in the return enable it• No other verbs will be cached regardless of headers
    • 19. HTTP
    • 20. Security• Date, URL, content can be combined and hashed • HMAC-SHA-1 with a secret key • API ID sent in a header • Used by many Amazon services

    ×