Time  Nick      Message
23:24 prologic  JSON Schema
23:04 sfisque   fumantchu_ "with extreme prejudice"   AMEN, preach on!  preach on!
22:07 Rotaerk   heading home
22:07 Rotaerk   anyway, you guys have given me enough to think about
22:01 Rotaerk   it then allows the client to switch to a different handler based on the media type
22:00 Rotaerk   but the custom media type would be json + some constraints (must have X, Y, Z objects in it)
22:00 Rotaerk   when I was saying to have a custom media type, I wasn't suggesting that you should roll your own basic data format; use json or something
21:59 whartung  no, it has semantics to how prmitivies and strcutures and collections are delimited.
21:59 fumanchu_ such reuse certainly makes the design of intermediaries, browsers, and tooling easier
21:59 Rotaerk   json, alone, is meaningless; no semantics
21:59 Rotaerk   not really
21:58 whartung  "anything" can read JSON
21:58 whartung  same reason everyone and their grandmother is jumping on JSON as a serialization format
21:58 whartung  commonality of data formats supports reuse for mundane plumbing. (why stream your own bitmap protocol, when you can use an off the shelf GIF library, for example, and get compression, etc. "for free")
21:57 Rotaerk   why not just infer all the semantics based on out-of-band communication
21:56 Rotaerk   whartung: what I'm unclear on is ... media types define semantics for data, for the client to rely on, so if you're going to be inferring semantics on top of that, why bother with media types at all
21:54 Rotaerk   will look at it at home
21:54 Rotaerk   bleh, my network blocks that for some reason
21:52 whartung  *image)
21:52 whartung  you'll note the semantics of the data type have not changed (GIF represent blocks of bits), but what those bit represent DOES change (it's no longer pixels of an imagine)
21:52 whartung  in this case, sending a 10,000 bit array as a GIF.
21:51 whartung  http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons
21:51 whartung  here's another example of using common media types for uncommon causes -- by Fielding.
21:36 Rotaerk   I'll have to look over that paper later
21:35 Rotaerk   I love "ADT"; refers to both "abstract data type" and "algebraic data type"
21:35 fumanchu_ (a la Cook: http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf)
21:34 Rotaerk   lemme look into it
21:34 * Rotaerk has never heard of HAL.
21:33 fumanchu_ I like to think of it as the difference between abstract data types and objects
21:33 Rotaerk   taking the policy of using generic media types to the extreme... you might as well just have one global media type, and rely on the client to know what it is
21:33 trygvis   that is not far from it. just replace the dictionary with a map of maps and add some links with relations and you have HAL
21:32 Rotaerk   it's meaninglessly reusable
21:32 Rotaerk   sure it's really generic and reusable, but it doesn't tell you the exposed members at the type level
21:31 Rotaerk   and using that in place of .. any other interface
21:31 Rotaerk   creating a C# interface called:  IInterface { Dictionary<string, object> Members; }
21:30 Rotaerk   to me it seems that the idea of using only generic media types, and then putting API-specific details on top of that is akin to...
21:30 fumanchu_ with extreme prejudice :)
21:27 Rotaerk   yea I plan to; I'm just working out the design while thinking about how REST should be applied
21:26 trygvis   I suggest you try to implement something instead of just reading
21:25 Rotaerk   the generic ones, fine; but not all need to be...
21:25 trygvis   you draw some really strange conclusions
21:25 Rotaerk   media types need not be reusable in other APIs
21:25 Rotaerk   though, I don't understand the problem with "single-purpose"
21:25 trygvis   settled is the wrong word, it is and will continue to evolve
21:24 Rotaerk   seems like REST should be redefined to account for that
21:23 trygvis   having a more specific media type is not useful, it becomes single purpose so instead the web has settled on a small set of generic media types and let applications layer requirements/expectations on top
21:22 Rotaerk   no guarantees
21:22 Rotaerk   trygvis:that's a good point; it could say "html" is the media type and instead return a bitmap
21:21 Rotaerk   so pointing out that there are sites which do it... doesn't help
21:21 Rotaerk   I'm just saying that it appears to be un-RESTful
21:21 Rotaerk   whartung: I never claimed that the approach of using out-of-band information to determine how to handle the returned content is not doable
21:20 whartung  but HTML is perfectly adequate for M2M transactions as well. Google somehow manages to suss out prices from God knows how many websites, using just HTML…imagine that…unpossible!
21:20 trygvis   Rotaerk: it's the internet, there are no guarantees
21:19 Rotaerk   the client in the case of HTML is the browser; the browser need not know the difference between a quantity and a shipping weight
21:19 whartung  HTML is enough to annotate the data (so the client can tell a quantity from a shipping weight), as well as what is a link and what is not.
21:19 Rotaerk   but a client that is looking for a link called X must expect a more specific media type...one that guarantees an X link
21:18 Rotaerk   html doesn't need to know anything about specific links; HTML is specific enough for rendering a web page
21:18 whartung  yes
21:17 Rotaerk   so the client must know how to process that media in order to know what links to expect, what semantics are associated with them
21:17 whartung  There is nothing in the HTML spec about what the "checkout" rel does
21:17 Rotaerk   but the links are provided within the media
21:16 Rotaerk   right
21:16 whartung  The CLIENT needs to be aware of the SEMANTICS of TRAVERSING the links.
21:16 Rotaerk   hmm
21:16 Rotaerk   a client application will require api-specific constraints though
21:16 whartung  Note this: "What they need to be aware of is … what semantics/actions are implied by traversing those links. "
21:15 Rotaerk   a browser doesn't need application-specific information in order to render a web-page
21:14 whartung  fair to assume that HTML is not Amazon specific, nor Wiki specific.
21:14 whartung  It's clear he's talking about HTML here, that much is obvious. Obviously, Amazon works just fine with a "web client" as well as wikipedia. Same media type, different applications.
21:12 whartung  potential transitions and anticipate the effect of chosen actions. A spider can follow them to the extent that the relationships are known to be safe. Typed relations, specific media types, and action-specific elements provide the guidance needed for automated agents."
21:12 whartung  "Think of it in terms of the Web. How many Web browsers are aware of the distinction between an online-banking resource and a Wiki resource? None of them. They don’t need to be aware of the resource types. What they need to be aware of is the potential state transitions — the links and forms — and what semantics/actions are implied by traversing those links. A browser represents them as distinct UI controls so that a user can see
21:12 whartung  Let me quote this:
21:12 Rotaerk   (not necessarily a bad thing if there are flaws in the original principles!)
21:11 Rotaerk   but it seems like what you're suggesting is that the community has deviated from the original principles; REST no longer refers to Fielding's rules very strictly
21:10 Rotaerk   err do prefer to *
21:10 Rotaerk   but I do approach to re-think it from the basics, rather than just go with the popular opinion
21:09 Rotaerk   community developed interpretations and whatnot can be useful to think about though; they might even make it better
21:09 Rotaerk   hmm, technical communities are susceptible to the bandwagon effect, which can lead to mass adoption of bad practices.  I'm not saying that's necessarily the case here... only that because of this, I don't treat popular opinion as more authoritative than well-thought-out, fundamental principles
21:04 whartung  also the dissertation is not the be all end all on this, we've been talking about this stuff for years and years.
21:03 Rotaerk   which would only be inherent to a more specific media type
21:03 whartung  but that's documented someplace else, not in the media type
21:02 Rotaerk   but still the client must "know" the semantics of those methods...
21:02 Rotaerk   granted, in the case of a representation of an API, that could be a generalized format:  a key-value pair mapping names to URIs for all the base resources reachable from the root node
21:00 Rotaerk   sure, have global media types; but not limit yourself to them
21:00 Rotaerk   the other principles, as I've mentioned, suggest an expectation that you do otherwise
20:59 Rotaerk   to suggest that it must be some global registry of media types is one way of interpreting it but... to build your service only in terms of those seems limiting, and not specifically discouraged by Fielding's paper
20:58 Rotaerk   he doesn't really seem to elaborate on "standard"
20:55 whartung  "REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability."
20:53 Rotaerk   also I don't see "use of common media types" in these fielding rules of REST
20:53 Rotaerk   seem to be saying that you should be defining media types
20:52 Rotaerk   seems to contradict that...
20:52 Rotaerk   "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state..."
20:51 whartung  a key tenet of REST is the use of COMMON media types in order to encourage "serendipitous reuse"
20:51 Rotaerk   a representation *
20:51 Rotaerk   whartung: but the representation of, say, an API which supports persons and places, is a format that provides a link to the persons resource, and a format that provides a link to the places resource
20:50 whartung  because there's no reason for application specific media types. They're unnecessary. Media type is simply a mechanism for creating REPRESENTATIONS of a resource.
20:50 Rotaerk   trygvis: I mean, I can't tihnk of what couldn't be done with *just* an entry point, and API-specific media type definitions
20:49 Rotaerk   API-specific media types *
20:49 Rotaerk   whartung: the whole point of a media type is to provide semantics to data, isn't it?  why not provide API-specific semantics with application-specific media types?
20:47 whartung  the media type documentation tells you the semantics of the media type. However, the semantics of the media type are NOT the semantics of the application. The media types RARELY have ANYTHING TO DO with the application -- thems completely different.
20:47 Rotaerk   trygvis: hmm it might be easier if you suggest something that you *can't* do?
20:47 Rotaerk   I can imagine how that would be sufficient
20:46 Rotaerk   that's what #6 seems to say
20:46 whartung  that's not enough
20:46 whartung  nope
20:46 Rotaerk   there is external documentation, but all it describes is how to process the media types
20:46 Rotaerk   whartung: that was never said
20:46 whartung  that the service is do all be all, and that with just an endpoint, all is elightenment
20:45 whartung  No, the idea that there's no such thing as external documentation.
20:45 Rotaerk   rule *
20:45 Rotaerk   whartung: the rest principle #6 is BS? o_O
20:45 whartung  utter, total, fly encrusted doody
20:45 trygvis   you always have an application/intent on top of the hypermedia, if not you really can't do anything
20:45 whartung  yea, that's complete BS Rotaerk
20:44 * sfisque goes afk
20:44 sfisque   be well all
20:44 sfisque   gotta bounce, but loved the discussion.  thx :-)
20:44 trygvis   what could you do?
20:43 Rotaerk   trygvis: hmm why not?
20:43 sfisque   as i understand it, if i specify image/tiff i should be delivering data that parses properly as a tiff image.  outside of that, you're working in the business logic arena and outside of what rest requires
20:43 trygvis   if you follow that interpretation there really isn't much you can do with anything
20:41 Rotaerk   the client should know nothing more about the service than the root URI, and the media types.  if they are assuming certain formats *on top of* the media types, then ... that is a violation
20:40 Rotaerk   though this is from rule #6 and seems to be more obviously violated by that:  "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API)."
20:37 Rotaerk   or if it refers to something more generic
20:37 Rotaerk   since this is REST and not HTTP, I'm not sure whether "methods" refers to GET/POST/PUT/etc
20:36 Rotaerk   hmm I may be misinterpreting "Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type"
20:33 sfisque   **not sure how
20:33 sfisque   not sure how?
20:31 Rotaerk   that's certainly possible; I'm just saying it seems like that violates that rule #3
20:31 sfisque   you could have a drools lib at some other node, and set of drools configs for validating endpoint request results
20:31 sfisque   csv and you publish some validation rules/schema/impl-lib at a different node in your tree and expose it for clients to DL and bind
20:30 sfisque   OR
20:30 Rotaerk   right
20:30 sfisque   x-csv-meeting-my-constraints
20:30 sfisque   now if you wanted to provide links to some form of schema in your hierarchy for validation, then that is part of your api
20:30 Rotaerk   so this disparity is resolved by making the media type be "csv-meeting-my-constraints"
20:30 Rotaerk   not just any *
20:29 Rotaerk   if the media type is "csv", then that means any csv is valid; but if the client requires a certain set of fields within the CSV... then not any CSV is valid
20:29 sfisque   at least as far as i understand rest
20:29 sfisque   that's interpretation and requires more than rest dictates
20:28 sfisque   regardless of whether the phone number is in slot 3 , slot 8, or slot 12
20:28 sfisque   right.  so if i get csv and the media type is csv, then 200 and all is good
20:28 Rotaerk   if your client expects a TIFF file, then you can receive a wrong TIFF file, but it's still valid
20:28 Rotaerk   sure, but i think the distinction here is validity versus correctness
20:27 sfisque   or engine
20:27 sfisque   and rules == human or some heuristic algorithm
20:27 sfisque   the fact that i can handle a tiff does not mean i got the right one when it arrives.  that requires rules
20:27 Rotaerk   vague :P
20:26 sfisque   media types are for "handling", not interpreting
20:26 Rotaerk   so then the client-side interpretation of the data is nothing more than the client handling that media type
20:26 sfisque   it depends
20:26 Rotaerk   then its media type shouldn't be CSV, but something more specific
20:25 Rotaerk   so for example, if your client needs to look for specific fields in your CSV file..
20:25 Rotaerk   I'm just saying that it seems like that third principle is saying that there should not be semantics pertinent to processing that lie outside the media type
20:23 sfisque   you can give them the "tools" but they can still use a shoe as a hammer
20:22 sfisque   but don't fight so hard for "control".  if they interpret incorrectly, its not your fault.
20:22 sfisque   right
20:22 Rotaerk   I'm not saying the client shouldn't do interpretation; it must
20:22 sfisque   which isnt terrible
20:21 sfisque   but lacking a "standard" for some context, you are pressed with either letting the client do its own interpretation (aka, the dev has to RTFM on your site) or you ship the impl to them
20:20 sfisque   then your fields are semantically defined for you
20:20 sfisque   UNLESS you adopt something standard, like x509 or similar
20:20 sfisque   when a tiff block is encountered there is a standard way to interpret it while cruising through a tiff file.  interpreting a "phone_num" field in your file, is proprietary, and the client either has to know how to interpret that OR you need to ship the interpreter with the data
20:19 sfisque   untrue.  the only difference here is standardization
20:19 Rotaerk   so if the media type was "csv", the client should do nothing about parsing it beyond having strings separated by commas
20:18 Rotaerk   a tiff rendering lib would be one way of "processing" the tiff, but it doesn't assume a higher level format aside from the media type "tiff"
20:18 sfisque   and yes, i realize i'm dating myself with references to opendoc :P
20:17 sfisque   unless, again, you attempt to ship the impl with the data (a la opendoc)
20:17 sfisque   you still need to know (at the client) what to do with that payload
20:17 sfisque   don't mistake "out of band information" with execution.  just because you need to load a tiff rendering lib does not mean REST is broken just because the server shipped you a TIFF file
20:16 trygvis   you always need to code your application, that is kind of obvious
20:16 Rotaerk   having some higher-level format on top of but not inherent to the media type qualifies as "out of band information"
20:16 trygvis   so if I have a collection+json client I can say "give me the URL if this item with rel='foo bar'"
20:16 Rotaerk   "Failure here implies that out-of-band information is driving interaction instead of hypertext."
20:16 sfisque   unless you attempt the "opendoc" manner and ship the execution with the data
20:16 Rotaerk   but that's what that rest principle seems to be *against*
20:15 trygvis   usually you have http client -> hypermedia client -> application client
20:15 sfisque   you always have to have that
20:15 Rotaerk   e.g. an XML schema on top of the generic format of "xml"
20:15 Rotaerk   so to parse them out, your client must have some knowledge about a format *on top of* that generic format
20:15 sfisque   minimally, i guess so
20:15 Rotaerk   right, so if your media type is something generic like that, the media type itself will not promise anything along the lines of... having a persons resource link and a places link
20:14 sfisque   if i send you links to an LDAP server, you need to follow those
20:14 sfisque   if i send you csv, you need csv parsing
20:14 sfisque   if i send you a BER block, you can parse out each bit according to BER extraction rules
20:13 sfisque   if the payload is delivered in a "standard" manner, the parsing happens natively.
20:13 trygvis   the "link relations" stuff comes in when you want to understand which is which
20:13 Rotaerk   if the media type is merely plain-text, there the only processing rules are to dump it into a string
20:13 sfisque   depends.
20:12 Rotaerk   so that the client, when implementing this media type, knows how to parse-out the two links with an understanding of which is which
20:12 sfisque   i cannot comment, my understanding of hateoas is still developing
20:12 Rotaerk   so the api node would need to have a media type... a format that provides a persons and a places link
20:11 sfisque   and you can always offer up your own x-blah refinements for cases to capture your resources, but defining that media type around "usage" rather than "what" is a possible unnecessary rabbit-hole i feel
20:11 Rotaerk   hmm, if I have an api which supports persons and places, and I use HATEOAS, the client would do a GET from the "api" node, expecting a representation that will provide it a link to the "persons" resource and to the "places" resource
20:11 sfisque   )
20:11 sfisque   but there ARE refinements of those generic flavors (like image/tiff
20:10 sfisque   yes
20:10 sfisque   media types (from a http standpoint) are defined around the "what" and not the "how" or "why" of a resource.  binary/octet-stream defines a binary stream, regardless of whether it is a BER block, an executable library, or such
20:10 trygvis   sfisque: you mean text/plain :)
20:08 sfisque   of course, but most are already defined.    for a simple plain text list   text/ascii is a valid return content type
20:07 Rotaerk   those are like "methods" of the resource
20:07 Rotaerk   well that seems to *imply* the use of media types I suggested earlier:  every desired transform on a resource (such as getting the count of persons or a list of the existing persons) would be a media type
20:06 sfisque   text/x-my-text-file-format
20:06 sfisque   application/x-my-media-type
20:06 sfisque   aye, that would apply to the x- media types.  any media type starting with "x-" is considered properitary and "context defined"
20:05 Rotaerk   ely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types)."
20:05 Rotaerk   "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entir
20:05 Rotaerk   well... actually.. :P
19:58 trygvis   :)
19:58 Rotaerk   think that's all of my questions/concerns for now
19:57 Rotaerk   well, thanks for the discussion and advice
19:55 trygvis   but for java there are several good clients and I know there are for other platforms too
19:55 Rotaerk   k
19:54 trygvis   I don't know how people do it in the .net world
19:54 Rotaerk   haven't looked into HTTP client libraries/frameworks
19:54 Rotaerk   err wait no, that's server...
19:54 Rotaerk   is the "HTTP client" layer something built in to ASP.NET, something built into ASP.NET Web API, or something that regardless of what framework you use, you would generally implement, yourself?
19:54 trygvis   for the query example, if the POST returns the body it can just give it to to the hypermedia layer, if it returns a redirect it will follow the GET and send that response to the next level
19:53 trygvis   that is kinda the whole point of specifying so much, to make it possible to reuse both semantics and code
19:53 Rotaerk   oh
19:53 trygvis   you usually have two layers, the generic HTTP client and the hypermedia-specific client
19:53 Rotaerk   and so it would be tailored to whichever the service chooses
19:52 Rotaerk   isn't the client generally custom implemented with the service in mind
19:52 Rotaerk   wait, what do you mean "any good HTTP client [will] handle both directly"?
19:51 Rotaerk   heh
19:51 trygvis   HTTP <3
19:51 trygvis   any good HTTP client handle both directly so the server can even decide on a per-request basis
19:50 trygvis   yep
19:49 Rotaerk   but if it's something that may be re-run, it's better to do it via GET for the sake of caching
19:49 Rotaerk   so if it's something that's likely to be one-off, creating a new URL to GET from is not practically any better than just returning the the results in the response from the POST
19:48 trygvis   not really depending on whether the query is big, but if it is likely that it will be fetched again soon
19:47 trygvis   but if you have a big query it might only be overhead if there will only be one GET later on
19:46 trygvis   that depends on your application
19:46 Rotaerk   ah, interesting
19:46 trygvis   some applications support POST to send big queries, but return an URL the client has to GET to see the result
19:46 Rotaerk   hmm URL parameters, though, are insufficient for non-trivial parameterization
19:46 trygvis   yes, you would loose the caching feature
19:45 Rotaerk   where the parameter is in the body of the request
19:45 Rotaerk   but, would it be an abuse to make a resource handle POSTs as essentially parameterized GETs
19:45 trygvis   only if the hypermedia told you how to create the post
19:45 Rotaerk   I mean, depending on the server to implement it this way
19:45 Rotaerk   hmm instead, is POST a valid means of requesting data from the resource, given parameters?
19:44 Rotaerk   k
19:43 sfisque   yah two types generally speaking, file format (jpeg vs. pdf vs excel, etc.) and content format (binary vs. text vs. image etc.)
19:42 trygvis   it's a list of media types, not hypermedias
19:41 Rotaerk   hmm yea they look mostly like file formats
19:41 trygvis   ^ that's all of the registered ones
19:41 trygvis   http://www.iana.org/assignments/media-types/media-types.xhtml
19:40 Rotaerk   wait, media types have to be a global standard?
19:39 trygvis   at least as long as you use valid media types (has to be "major/minor")
19:39 trygvis   well, it would work but you're not following its intent
19:38 Rotaerk   hmm how is it an abuse as far as the standard is concerned
19:38 trygvis   all of the above
19:37 Rotaerk   is it working against the HTTP standard, or the concept of REST, or just the conventional application of them?
19:37 trygvis   then you're certainly working against the system
19:37 Rotaerk   etc
19:37 Rotaerk   "list" to get a list of them
19:36 Rotaerk   so I could do a GET with the media type being "count" from the persons resource, to get back the number of persons
19:36 Rotaerk   not merely an encoding
19:36 Rotaerk   media type = transformation/view of the resource
19:35 trygvis   for what?
19:35 Rotaerk   can't actually think of anything wrong with using media types for that, then, apart from that it's not the popular way to do it
19:33 Rotaerk   just not necessarily *where* the resources are
19:33 trygvis   you request what you support, the server respond with the best it can offer you
19:33 Rotaerk   *functionality* isn't discoverable anyway... the client needs to know how to use it anyway
19:33 Rotaerk   then again...
19:32 Rotaerk   so the functionality wouldn't be discoverable via HATEOAS
19:32 trygvis   right. and that is a feature :)
19:32 Rotaerk   you can't exactly *link* to one specific media type of the resource
19:32 Rotaerk   I guess one problem with thinking of media types as, essentially, arbitrary views/methods of the resource is...
19:29 trygvis   but yeah, I doubt content negotiation is the most used feature out there
19:27 trygvis   it's choice. and it makes it easier to move stuff later on
19:27 Rotaerk   well, N separate resources
19:26 Rotaerk   don't see anything you can do with media type that can't just as easily be done by just creating two separate resources
19:26 Rotaerk   it seems like HTTP has some... redundant features
19:26 trygvis   so you can browse the "machine" media type directly
19:26 trygvis   but it turns out to be lot of work for those who write the server, so people instead create clients for HAL and C+J
19:25 trygvis   some people like it that way
19:25 Rotaerk   and if you request the html media type, you get the same data formatted for presentation
19:25 Rotaerk   so if you request the log media type, you get raw data, for use by software
19:24 Rotaerk   hmm what about this then:  supporting a "log" media type and an html media type
19:22 trygvis   so the person has pointers to the other resources
19:21 trygvis   so you could have a person resource with links, and your app would follow the "log life" rel or "log medical" rel
19:21 trygvis   yes, but the content type is "log". the application tells you what kind of data that is available
19:20 Rotaerk   I thought the media type was the mechanism for content negotiation
19:20 Rotaerk   hmm but when the client wants to request the medical visit only, how do they do that?
19:19 trygvis   a more useful approach would have application/log which contains entries of type=life-log and type=medical-visit
19:18 trygvis   Rotaerk: that is one way to do it, but it's not very useful
19:17 * sfisque personally dislikes json
19:17 Rotaerk   etc
19:17 Rotaerk   and then "medical history" media type, might list their medical history
19:17 Rotaerk   but would, say "biography", be a valid media type for a "person" resource, where the resulting representation is a log of the person's life
19:17 trygvis   . o O (but still people love it)
19:17 trygvis   json is almost as dumb as you get it
19:16 Rotaerk   json is just a simple-stupid "encode the entire resource as JSON"
19:16 Rotaerk   so the accepted media types are representative of arbitrary functions applicable to the resource
19:15 Rotaerk   as in, different media types can report different aspects of the same resource
19:15 Rotaerk   are they supposed to represent just the encoding of the data, or are they supposed to represent a *view* of the data
19:15 Rotaerk   on a different note, something about HTTP that I'm vague on is media types
19:13 trygvis   you can't exchange one for the other
19:13 trygvis   sfisque: but those user accounts are not the same resource
19:13 sfisque   in one system, i am a SSI, in another i am an email addy, in another i am some generated serial number, etc.
19:12 sfisque   that is not irreconcilable.  i have many id's across many systems
19:12 trygvis   amazon does what you seem to suggest Rotaerk, all users and other objects are URNs which is resolved through their API
19:12 Rotaerk   it means that if multiple URIs can refer to the same entity, and the URI is the ID, then that means an entity can have multiple IDs simultaneously
19:12 sfisque   then you get into resolution, redirection, etc.
19:12 sfisque   but, as mentioned, the more indirection your api provides, the muddier it will be to your implementers/clients
19:11 trygvis   I guess the problem is that there isn't any other definition of identity so people just use the URI
19:11 sfisque   yes.  afaik a URL/URI is a "unique location" but not has never been defined as a "unique entity"
19:11 trygvis   they can, but then you loose much of the usefulness of the current implementation
19:10 Rotaerk   multiple resources can point to the same entity
19:10 Rotaerk   I read through the Roy Fielding paper on REST, and it seemed to make it clear that "resource" is just a node bearing semantics and doesn't have to uniquely refer to an entity
19:10 trygvis   ^ ref the urn/uri/url
19:10 trygvis   http://tools.ietf.org/html/rfc3986#section-1.1.3
19:08 trygvis   again, you can always create other ways to implement your way, but it will work against The Web
19:08 trygvis   yes, and it say if it is a temporary or permanent move too
19:08 sfisque   depending on the details
19:08 sfisque   or similar
19:07 sfisque   the server can always send a "Resource Moved"
19:07 sfisque   trygvis that makes more sense, and captures the intent of that directive
19:07 trygvis   the URL is opaque, you can't fiddle with it
19:06 trygvis   so /api/resolve/person=123 would redirect you to /api/person/123 or http://s3.amazon.com/234782364872346
19:06 Rotaerk   if the IDs are *relative*, then the site can move without breaking the IDs
19:06 trygvis   Rotaerk: I think the alternative is to let the server to the resolution with a redirect
19:06 Rotaerk   trygvis: well, the way it's restrictive is that the identity of the *entity* is dependent on the site itself remaining in the same place
19:06 trygvis   like HAL and C+J
19:06 trygvis   other hypermedias may have similar techniques, but modern hypermedias use the URLs as identifiers
19:05 trygvis   atom does it that way because two atom document may include the same entry
19:05 sfisque   aye
19:05 trygvis   sfisque: not if you have to go through a resolver
19:05 sfisque   and ID is just an opaque identifier
19:04 sfisque   it's no more restrictive than saying  x  = 2342344234234
19:04 trygvis   atom has it's own definition of ID
19:04 sfisque   how is it "restrictive"?  i don't see how that follows
19:04 trygvis   it may be, but it's the most useful thing you have unless you start looking into the hypermedia
19:03 trygvis   right, so doesn't that mean that http://.../api/persons/123456789 is always available
19:03 Rotaerk   it just seems to me though that it's overly restrictive for entity IDs to be the full URL
19:03 Rotaerk   (until you retire it)
19:02 Rotaerk   so the root might change to no longer *point* to a resource, but the resource itself is still resolvable if you go to it directly
19:02 Rotaerk   I suppose what's ephemeral is the linkage between resources... not necessarily the resources themselves, and their locations
19:02 trygvis   Rotaerk: if all URLs are ephemeral, how can you even resolve something? after is has been resolved, may be gone
19:01 sfisque   i don't see that being reconcilable without hand-waving
19:01 sfisque   not just representatin
19:01 sfisque   but now we're talking about state being tied to location
19:01 Rotaerk   well, *might* be changing state
19:00 Rotaerk   when you POST/PUT, you're changing state
19:00 Rotaerk   there's naturally going to be state in the resources themselves
19:00 Rotaerk   (the representation is complete)
19:00 Rotaerk   it implies that the representation doesn't depend on any contextual state for it to make sense
19:00 Rotaerk   REST doesn't imply lack of state, everywhere
18:59 sfisque   by definition
18:59 sfisque   if an object's "location" can suddenly change at any given point, then it's location is stateful
18:59 sfisque   your comment slipped in between
18:59 Rotaerk   yes I got that :P
18:58 sfisque   bah, i was referencing what trygvis said
18:58 Rotaerk   how does that imply state?
18:58 Rotaerk   even if it's not something that changes frequently
18:58 sfisque   that is a good point.  if ALL URI's are ephemeral that intrinsically assumes state
18:58 Rotaerk   well "assuming you can always go back to the old location" seems to be a violation of REST :\
18:57 Rotaerk   heh
18:57 trygvis   [citation needed]
18:56 trygvis   without it the whole stateless-ness thing won't work
18:56 Rotaerk   "The URN concept was formally defined in 1997, and in 2005, to avoid confusion with the term "URL", the use of the terms URL and URN has been deprecated in favor of the less-restrictive "URI" (illustrated)."
18:56 trygvis   Rotaerk: but I wouldn't sweat it and just assume that you can always go back to the old location
18:56 trygvis   ;)
18:56 pdurbin   there is only one REST wiki to trust
18:56 trygvis   but the principle still applies
18:55 trygvis   I wouldn't trust wikipedia when it comes to technical content
18:55 Rotaerk   that URL is an informal thing, and URN is ... replaced by URIs
18:55 trygvis   uh?
18:55 Rotaerk   according to wikipedia, there's only URI now
18:54 trygvis   an URI is both URN and an URL, a URL is a specific location which can be accessed and URN *has* to be resolved to a location before it can be accessed
18:53 Rotaerk   k
18:53 trygvis   right, that's is the URN way
18:52 Rotaerk   and then you could request the current URL for person:123456789 from the API, and it'd give you http://.../api/persons/123456789
18:52 Rotaerk   (another URI)
18:52 Rotaerk   the permanent ID could be ... person:123456789
18:52 Rotaerk   but that's just the *current location* of the person entity
18:51 Rotaerk   I was thinking maybe if I had, say, a database of people, the URL would be:  http://.../api/persons/123456789
18:50 trygvis   but I would hate your API :)
18:50 trygvis   an alternative is to use URNs if you want to force the client to have a client-side resolver
18:49 trygvis   but they really are supposed to be picked up again at any time
18:49 trygvis   well, they *should*be useful at least for as long as the resource they where referenced from is cacheable
18:48 Rotaerk   I'm just not really clear on how to resolve that
18:48 Rotaerk   HATEOAS seems to suggest that all URIs apart from the root one are ephemeral
18:47 Rotaerk   but it *does* break things if the client needs to persist some kind of entity reference
18:47 Rotaerk   but that doesn't affect the client because they navigate through the links provided
18:47 Rotaerk   no it says the freedom to *control* the hierarchy; taking HATEOAS into account, it suggests that it can change the hierarchy all it wants
18:46 trygvis   they have the freedom to have their own hierarchy, but they can't change it
18:45 Rotaerk   above
18:45 Rotaerk   but that seems to violate the REST principle
18:45 trygvis   the URI is a very good identifier to store
18:45 Rotaerk   these identifiers would be fixed, and not tied to the topology of the resource hierarchy
18:44 Rotaerk   so does that mean the service should have a separate identification scheme for entities, and a way of dynamically mapping these identifiers to the corresponding URI
18:44 Rotaerk   "A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace."
18:44 Rotaerk   given the rules of a RESTful service, it seems like if the client needs to store the identifier for a resource... it should *not* be the URI