RESTful web service development: Difference between revisions

From Bitpost wiki
No edit summary
No edit summary
 
Line 1: Line 1:
[http://www.xfront.com/REST-Web-Services.html REST] is LIGHT, uses HTTP to define interface, including HTTP verbs (GET,POST,PUT,DELETE) + URL parsing + URL parameters
== REST summary ==
== REST summary ==
* every resource has to be discoverable via links
* every resource has to be discoverable via links
Line 26: Line 28:
#The other excellent example is the [http://docs.amazonwebservices.com/AmazonS3/latest/index.html?RESTAuthentication.html Amazon S3 API].  Authentication is brilliant - it uses a SHA1 signature of the request, which MUST include a timestamp within the last 15 minutes.  There is a set of rules for turning the request URL into the request string that is signed.
#The other excellent example is the [http://docs.amazonwebservices.com/AmazonS3/latest/index.html?RESTAuthentication.html Amazon S3 API].  Authentication is brilliant - it uses a SHA1 signature of the request, which MUST include a timestamp within the last 15 minutes.  There is a set of rules for turning the request URL into the request string that is signed.
  Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );
  Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );
* Some REST tech: Apache Axis2 (Java or C), PHP HOWTO's [http://www.gen-x-design.com/archives/making-restful-requests-in-php/ 1] [http://www.fliquidstudios.com/2009/01/13/introduction-to-writing-a-rest-server-in-php/ 2], [http://www.recessframework.org/section/tutorials PHP recess library]

Latest revision as of 16:03, 18 November 2016

REST is LIGHT, uses HTTP to define interface, including HTTP verbs (GET,POST,PUT,DELETE) + URL parsing + URL parameters

REST summary

  • every resource has to be discoverable via links
    • basically a developer can learn the API with a browser
    • also, with links, you can mingle resources from any REST api
  • verbs
    • GET - retrieve a specific resource
    • DELETE - delete a specific resource
    • PUT - update a specific resource
    • POST - create a new resource and return the ID - neither safe nor idempotent
  • you can repeat calls to GET/DELETE/PUT all day long if they fail
  • to provide complex functions (eg query and result) as resources...
    • create a query resource with a TTL
    • add to it
    • execute it (and auto-release?)
    • release it (or let this happen automatically with server-side TTL cleanup)
  • how do we handle huge lists? like this?
    • wya/users
      • returns the first 10 users with a link to next 10
    • wya/users/range/11-20
      • a link to users 11-20
  • {resource}/edit should return an edit form (cool) - I think recess already does this?
  • authentication - use SSL with HTTP Basic Authentication, or SHA1 signature (ala Amazon S3)

REST Examples

  1. The best example I have to follow is the Twitter API. It *obviously* scales. It uses Basic Authentication, which sucks (everything is plaintext, holy shit). BETTER force it to use SSL.
  2. The other excellent example is the Amazon S3 API. Authentication is brilliant - it uses a SHA1 signature of the request, which MUST include a timestamp within the last 15 minutes. There is a set of rules for turning the request URL into the request string that is signed.
Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );