6 10-presentation

1,068 views
1,026 views

Published on

First presentation of the rest3d working group. Presented by Rémi Arnaud, during the WebGL camp #3 http://www.webglcamp.com

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,068
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

6 10-presentation

  1. 1. rest3d<br />3D REST style<br />http://rest3d.org<br />Rémi Arnaud<br />
  2. 2. What is REST ?<br />Roy Fielding dissertation (2000) http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm<br />Representational State Transfer (REST) is an architecture, not a standard. <br />REST is based on http, xml, uristandards<br />REST is everywhere already<br />twitter API http://dev.twitter.com/doc<br />Dropbox API https://www.dropbox.com/developers/docs<br />Google MAP API Web services http://code.google.com/apis/maps/documentation/webservices/index.html<br />….<br />
  3. 3. 6 constraints for a RESTful API<br /><ul><li>Client–server Clients are separated from servers by a uniform interface. Clients are not concerned with data storage, Servers are not concerned with the user interface or user state. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.
  4. 4. Stateless Client context is not stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client. The server can be stateful; this constraint merely requires that server-side state be addressable by URL as a resource
  5. 5. Cacheable As on the World Wide Web, clients are able to cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.
  6. 6. Layered system A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load balancing and by providing shared caches. They may also enforce security policies.
  7. 7. Code on demand Servers are able to temporarily extend or customize the functionality of a client by transferring logic to it that it can execute. Examples of this may include client-side scripts such as JavaScript.
  8. 8. Uniform interface The uniform interface between clients and servers simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are:Identification of resources (e.g. URI), Manipulation of resources, Self-descriptive messages, Hypermedia as the engine of application state</li></ul>http://http://en.wikipedia.org/wiki/Representational_State_Transfer<br />
  9. 9. methods<br />PUT and DELETE are defined to be idempotent - multiple identical requests should have the same effect as a single request<br />POST is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects<br />See also HEAD, OPTIONS and TRACE methods<br />Potential use:<br />http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html<br />
  10. 10. What is REST 3D ?<br />3D as a web service<br />http://rest3d request<br />Web Server<br />Client application<br />Response document<br />Cloud Storage<br />
  11. 11. Multiple services – same API<br />Web Server<br />Web Server<br />Web Server<br />Client application<br />Cloud Storage<br />Cloud Storage<br />Cloud Storage<br />
  12. 12. Multiple applications<br />Client application<br />Web Server<br />Web Server<br />Web Server<br />Client application<br />Cloud Storage<br />Cloud Storage<br />Cloud Storage<br />Client application<br />
  13. 13. rest 3d methods<br />Potential use model:<br />http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html<br />
  14. 14. Use case 1 – content gathering<br />Program interface to content repositories. Current state requires human in the loop, and content creation tool to explore the model.<br />http://sketchup.google.com/3dwarehouse/<br />http://www.3dvia.com/<br />http://www.3dcadbrowser.com/<br />http://www.3d02.com/<br />http://www.turbosquid.com/<br />…<br />
  15. 15. Use case 1 – content gathering<br /><ul><li>search – return models matching with metadata search
  16. 16. browse – Avoid downloading all the 3D models that matches the search, this feature provides information about the models such as number of polygons, date, tool used to create the model, …
  17. 17. traverse – explore the model hierarchy, and sub parts or/and categories.
  18. 18. dependencies - list all the dependencies, for instance the list of textures, shaders, or other parts of the model
  19. 19. filter – select only the parts needed by the client. Allows for texture/3D LOD selection, paging…
  20. 20. download – get selected subset of the model in a specific format. </li></li></ul><li>Use case 2 – collaborative browsing/viewing<br /><ul><li>search – return models matching with metadata search
  21. 21. scene – Create a scene and position the models in the scene
  22. 22. viewer – extend the client with a viewer application (<embed>) of the created scene.
  23. 23. collaborate – enable multiple applications/users to interact with the scene
  24. 24. store – store the created scene for others to discover
  25. 25. link– provide a URL to the scene</li></li></ul><li>Use case 3 – content repository<br />Content gathering API plus:<br /><ul><li>create– add models to the content repository
  26. 26. update – modify an existing model
  27. 27. version – server list all the different versions available, with metadata
  28. 28. diff / merge – provide tools to show the difference between versions
  29. 29. process – provide tools to process the models, mesh optimization, texture atlas,
  30. 30. convert – covert a model from one format to another as a web service.</li></li></ul><li>insert your use case here<br />Join the discussion:<br />http://groups.google.com/group/3d-rest<br />
  31. 31. Typical xml ‘model’<br />http://scenejsorg.ipage.com/dist/curr/extr/examples/tron-tank/extras/tron-tank-model.dae<br />
  32. 32. XML & XHTML<br />Embed 3D in html page<br />http://www.xml3d.org/<br />http://www.x3dom.org/<br />Dynamically load 3D into DOM <br />(o3d) http://capstone.azurenet.net/web3d/demo/<br />varfloat_array=textValue.split(" ").map(parseFloat); <br />DOM (jquery) allow for fast tree parsing/modifications<br />Direct XML export (POST/PUT) to server<br />
  33. 33. Typical json ‘model’<br />https://github.com/mrdoob/three.js/blob/master/examples/obj/Suzanne.js<br />myData = JSON.parse(text, function (key, value) { <br />if (value && typeof value === 'object') {… return value; }});<br />Need convention for attributes vs value, not easy to go back to XML<br />
  34. 34. Typed Array<br />http://www.khronos.org/registry/typedarray/specs/latest/<br />
  35. 35. Typed Array loading<br />function onLoad(){   var canvas = document.getElementById("lesson01-canvas");   initGL(canvas);                                    varxmlhttp = new XMLHttpRequest();   xmlhttp.open("GET", "cube.bm", true);   xmlhttp.responseType = "arraybuffer";               xmlhttp.onload = function()    {      var buffer = xmlhttp.response;      gl.bindBuffer(gl.ARRAY_BUFFER, buffer);                      // Reading Data      var v1 = new Float32Array(buffer);                     alert(v[0]);  // This works fine.   }   xmlhttp.send();                        }<br />
  36. 36. Leaving the REST to YOU?<br />Official web page<br />www.rest3d.org<br />Join the discussion:<br />http://groups.google.com/group/3d-rest<br />

×