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.