architecting web services

Download Architecting Web Services

If you can't read please download the document

Upload: lorna-mitchell

Post on 19-May-2015

6.493 views

Category:

Technology


1 download

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