Time Nick Message 16:04 ironChicken np :-) 16:02 fumanchu good choice 16:02 NOPonPOP thanks for discussing it with me 16:01 NOPonPOP i think since logically the way me and my users will think of this data is a directory tree (this is actually a front end to what used to be command line tools) it still makes sense for me to use that in the url. i think ill apply your principal of 1:1 request/object to solve multiple chart handling 15:59 ironChicken nebulous is a good way of putting it 15:59 NOPonPOP https://www-01.ibm.com/support/knowledgecenter/SSPT3X_3.0.0/com.ibm.swg.im.infosphere.biginsights.admin.doc/doc/admin_fileupload_rest_apis.html 15:58 NOPonPOP and let the client do the rendering of that 15:58 NOPonPOP so i just return json data structures now that contain the raw data i want to plot 15:58 NOPonPOP the biggest thing i wanted for my API was to decouple data and its representation 15:57 NOPonPOP seems very open to interpretation? 15:57 NOPonPOP i dont mean that as an insult or anything 15:57 NOPonPOP i feel REST is kind of nebulous 15:57 NOPonPOP ironChicken: heh https://www.npmjs.com/package/restfs 15:54 ironChicken NOPonPOP: yes, that's right, no nesting of URIs. nesting *implies* a hierarchy; instead you should make your hierarchy explicit in the semantics of the response 15:54 NOPonPOP but if i do that, it seems like im just moving the data structure around, but still using the same file tree data structure 15:53 NOPonPOP i can imagine a world in which i represent the directory stucture as one flat area, and then basically recreate the 'file system' using response data as you have described 15:52 NOPonPOP from the abstraction in this api 15:52 NOPonPOP you can see im having a hard time seperating the underlying directory structure im really representing 15:52 NOPonPOP is that intentional? 15:52 NOPonPOP in that example, there is no nesting of those URIs 15:52 NOPonPOP now back to your previous response 15:52 ironChicken s/principal/principle/ 15:52 NOPonPOP that helps me actually 15:51 NOPonPOP ok 15:51 ironChicken i like the principal that each URI represents exactly one resource, and that each HTTP GET request is for exactly one URI 15:50 NOPonPOP 11:16 < NOPonPOP> rather than sending data about multiple things in a single server response, if that makes sense 15:50 NOPonPOP 11:16 < NOPonPOP> and accumulate data on the client side 15:50 NOPonPOP how about this last bit: 11:16 < NOPonPOP> if thats the case, then it seems like for a given http request, i can only operate on a single item at a time. so ill have to dispatch a GET for each 15:50 ironChicken even better is the client does: GET /31d88326-f7f5-11e4-b90f-0021ccd2abe3 and the response says that this resource is a 'child', it has a parent called 'containers' (at URI /4cf2f808-f7f5-11e4-b1f5-0021ccd2abe3) and that is has a list of children (with URIs for each) 15:50 NOPonPOP rather than sending data about multiple things in a single server response, if that makes sense 15:49 NOPonPOP and accumulate data on the client side 15:49 NOPonPOP if thats the case, then it seems like for a given http request, i can only operate on a single item at a time. so ill have to dispatch a GET for each 15:48 NOPonPOP which then triggers GET /containers/child_1/file1 15:48 NOPonPOP and the response tells him abou tfiles/file1,file2,file3 15:48 NOPonPOP like are you saying the client does GET /containers/child_1/ 15:47 NOPonPOP can you give me an example of ho wyou might represent the same underlying data according to what youve said? 15:46 ironChicken don't make clients guess the hierarchy from the URIs 15:46 ironChicken if you have a hierarchy, then the response data should encode information about the structure of that hierachy by telling clients where they can go next 15:45 ironChicken URIs are just unique identifiers for things 15:45 ironChicken NOPonPOP: don't embed implied semantics in the URIs 15:40 NOPonPOP im not even sure how to respond to that, am i missing something completely here? 15:40 NOPonPOP some people have said thats not restful at all 15:40 NOPonPOP when i want to render charts for multiple children, i simply cant figure out what that URL should look like, a single chart should look like /containers/child_dir1/files/file1 15:39 NOPonPOP i feel like ive read all these links and developed some kind of rudamentary understanding of rest, except for the urls. the data structure i need to represent is a directory tree. inside the parent, there are child directories which contain databases i want to draw charrts for. eahc child directory can contain multiple databases, and there can be an unlimited number of child directories. all children sit beneath the same parent.