architecting web services
TRANSCRIPT
- 1. Architecting Web Services Lorna Mitchell, Ibuildings
2. About Me
- PHP Developer/Consultant/Trainer with Ibuildings
3. PHP community evangelist 4. Blog athttp://lornajane.net 5. Web Services
- Provide information in machine-readable format
6. For local or remote consumption 7. For consumption by discrete/modular systems 8. Why Web Services 9. Why Web Services 10. Why Web Services 11. Why Web Services 12. Service Types
- RPC (Remote Procedure Call)
13. SOAP 14. REST (REpresentational State Transfer) 15. RPC
- All URLs point to a single endpoint
16. Parameters give method names 17. Request body can take a variety of formats 18. RPC Advantages
- RPC is a great format for wrapping existing functionality
19. Can abstract between existing systems 20. Familiar functional paradigm 21. RPC Example Flickr's XML-RPC Request flickr.test.echo name value name2 value2 22. RPC Example Flickr's XML-RPC Response [escaped-xml-payload] 23. Delivering RPC
- Consumers will need
-
- Service URL
- 24. Docs of functions and arguments
25. If this was an existing system, existing docs may suffice 26. SOAP
- Special case of RPC using XML
27. Has given formats for messages and errors 28. Libraries exist for creating server and client in most languages 29. PHP SOAP Server Example require_once('lib/myClass.php'); ini_set("soap.wsdl_cache_enabled", "0"); $server = new SoapServer("service.wsdl"); $server->setClass("MyClass"); $server->handle(); 30. PHP SOAP Client Example ini_set('soap.wsdl_cache_enabled','0'); require_once('lib/Snapshot.php'); $wsdl = "Service.wsdl"; $client = new SoapClient($wsdl, $params); $output = $client->requestShot( 'http://www.php.net','', 300, 400); 31. WSDL
- Web Service Description Language
32. Widely used with SOAP 33. Describes the methods, arguments and data types available 34. IDEs can read this and hint 35. Validity of requests is checked before they are sent 36. WSDL 37. Delivering SOAP
- In WSDL mode, only the WSDL needs to be supplied
38. Otherwise method names, arguments and types will be needed 39. REST
- A series of concepts
40. Generally uses HTTP (HyperText Transfer Protocol) 41. URLs are resource locations 42. Verbs tell the service what to do 43. Status codes indicate what the outcome was 44. Implementing REST
- Standard application architecture
45. Routing to map requests to internal functionality 46. Output not always HTML 47. REST Examples
- GET http://example.com/users/lorna
48. POST http://example.com/users 49. PUT http://example.com/users/lorna 50. GET http://example.com/users 51. Delivering REST
- Full documentation including URL formats, data types, and response formats
52. Must include information about error handling 53. REST as an inspiration
- RESTful is a strict definition
54. REST is full of great ideas 55. REST is great for clean, simple, robust services 56. Cherry-pick the bits that work
- Just don't call it "RESTful" :)
57. General Architecture Considerations 58. Machine-Readable Formats 1111011110101000001101011011110001001101011111011000101010001011010100001110110111101001111110011100110010100110011000111100011000000111100000011001001101000001011100101101011011100010010111000001111010000100100010010101010101110110000000100101101110100000111001000010100010011111111010001010110000010100000101011000001000000100110000100100110010101001110101100001010110001111000101110111011110010011110101101100110111100111101000001010100100110111001111111010000000000111000000011101000000010011001101100110000101011111010100111011100100000000111010010110100011110110111000011100000010111010010011111011001001010110111011111101110000011111100010010000011010100010010011100000111111101100111111000001000100101011011100001101111011100010101010011000000100011011010000111010000000001100010011011011010010000101110111110110111101110111000111010100001001101011010101110101010100111000010110001110001111001011100011110100000110100110000000100011101011010010011100111011001111111011111000011101000111100110 59. Machine-Readable Formats
- XML (eXtensible Markup Language)
60. JSON (JavaScript Object Notation) 61. Key/value pairs 62. Form variables 63. Background: XML
64. Background: JSON {"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": "CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } }} 65. Choosing Formats
- XML needed for SOAP, widely supported in most languages
66. JSON easier for JavaScript, use with AJAX-esque requests 67. Or make both available 68. Use built-in libraries for your platform 69. Error Handling
- Will you ignore extra fields?Error?
70. How about incorrect data types?Cast or reject? 71. Make error messages meaningful and unique 72. Asynchronous Handling
- Consider swift response and offline processing
73. Manage job queues and retries 74. Will users poll for a change? 75. Could implement callbacks 76. Versions and Formats
- Include as parameters to your service:
-
- The service version (allows for future upgrades)
- 77. The preferred response format
78. Building Blocks
- Some frameworks have functionality built-in for services
79. Can be convenient 80. Consider performance 81. Resources
- RESTful Web Services Leonard Richardson and Sam Ruby
82. http://uk.php.net/sca 83. http://benramsey.com 84. http://lornajane.net 85. 86. WSDL 87. WSDL: Service 88. WSDL 89. WSDL: Binding 90. WSDL 91. WSDL: Port Type 92. WSDL 93. WSDL: Message