[00:19:43] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest. [00:20:38] Wombert (~Wombert@84.233.128.147) joined #rest. [00:21:16] Wombert (~Wombert@84.233.128.147) left irc: Client Quit [00:35:39] ivanfi (~ivanfi@62.159.77.167) joined #rest. [02:06:08] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [02:24:03] Blazeix (~Blazeix@71.74.190.197) left irc: Read error: Operation timed out [02:24:53] Blazeix (~Blazeix@71.74.190.197) joined #rest. [02:24:56] kevwilde (~kevwilde@igwe16.vub.ac.be) joined #rest. [02:25:53] Howdy, i'm creating a REST api, but i need an url that allows me to send a mail, but /mail is a verb, what do you think is the best strategy to be as close to REST as possible? [02:41:40] DracoBlue1 (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [02:43:41] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Ping timeout: 252 seconds [02:44:10] kevwilde: URI design is orthogonal to REST. REST does not care. [02:44:22] mail is both a verb and a noun [02:45:07] so i can have a /mail which only takes a POST method? [02:45:41] if you use REST in context of HTTP yes [02:45:50] REST != HTTP [02:46:41] we're using it in an HTTP context, i believe this is the most common practice, do you have examples of REST in other contexts? [02:48:08] it is possible to to do REST over a multitude of protocols. HTTP is the most common. FTP is another [02:49:01] REST is an archtectual style. [02:49:55] and IMO POSTing to /mail isn't very resourceful, but that's just me [02:50:26] (unless it creates a mail-resource) [02:50:30] Jarda: how would you handle the case? [02:50:48] It must be hypermedia driven [02:50:55] kevwilde: I would maybe put my client actually handle the mail sending [02:51:14] or then the mailing should be a side effect [02:51:31] but I don't get why you would want to have a "mail" resource [02:51:57] Jarda: the problem is that the API is of a server containing all business logic, sending and resending a mail is part of the business scope [02:52:16] sending is a side effect, but resending the mail should be possible too [02:52:29] kevwilde: ok, so then you actually have mail-resources [02:52:33] and it makes sense [02:52:45] because every sent mail should have an identifier [02:52:54] so you don't have a resource sending mails [02:52:55] i don't save them in my database, though [02:53:03] but you have a collection of mail-items [02:53:11] how can they be re-sent if you don't store them? [02:53:31] i have a collection of tickets, those can be sent by mail [02:54:00] eh [02:54:08] they get sent when created, but i should be able to resend the tickets [02:54:22] ah. that is quite possible [02:54:39] do you mean some kind of "resend"-button, to notifiy everyone who is connected to the ticket? [02:54:44] Nick change: DracoBlue1 -> DracoBlue [02:54:45] you can do whatever you want, but /tickets/123/mail isn't REST, its's RPC [02:54:54] (IMO) [02:54:57] DracoBlue: yes, something like that [02:55:23] Jarda: if there is no real REST way, i'll have to go REST-RPC hybrid-like [02:55:38] what about POST to /tickets/123/reminders or something like that? [02:55:42] each ticket SHOULD have a and that resource could for instance take a list of tickets, maybe in the form of text/uri-list" [02:55:58] and afterall, it doesn't really matter, as long as the identifier is identified by hypermedia [02:56:14] Ngarthl: i'm not writing HTML, i'm writing an HTTP API [02:56:24] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Remote host closed the connection [02:56:29] kevwilde: hypermedia isn't restricted to html.. [02:56:40] i'm just writing the API backend [02:56:44] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [02:56:44] ever heard of HATEOAS? [02:56:51] if not, then our serfice isn't REST [02:56:55] *your [02:57:10] Jarda: hearing about it ain't enough ;) [02:57:21] Ngarthl: :) [02:58:01] JSON + HTTP != REST [02:58:10] Hypermedia + HTTP == REST [02:58:23] very simplified [02:58:56] Hypermedia MAY of course be encoded in JSON, but JSON in itself is not. The same with XML. [03:00:14] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit [04:11:02] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [04:14:15] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit [04:24:01] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [04:27:06] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit [04:31:05] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 260 seconds [04:31:39] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [05:00:05] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest. [05:49:15] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [05:50:36] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Client Quit [05:56:03] tomayac (~tomayac@213.61.101.1) joined #rest. [06:02:49] tomayac (~tomayac@213.61.101.1) left irc: Quit: tomayac [06:03:11] tomayac_ (~tomayac@213.61.101.1) joined #rest. [06:19:43] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest. [06:21:11] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove [06:24:35] mamund: did you see I made a pretty picture for HAL ? [06:27:19] mikekelly: links? :) [06:28:48] http://stateless.co/info-model.png [06:29:51] I think that makes sense [06:29:57] it makes sense to me [06:46:51] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) joined #rest. [06:48:29] mamund: URI pattern craziness from joe gregorio https://plus.google.com/u/0/118148240205592032989/posts/Vxu7xgaBnnc [07:01:15] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [07:21:59] Action: mamund slides in [07:22:21] mikekelly: nice pic [07:22:51] interesting rendering of href as "outside, but related"? [07:24:40] mikekelly: missed the plus convo, thanks for the pointer. [07:26:13] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [07:26:29] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit [07:26:41] mamund: did that href bit make sense [07:28:25] looks like I'm wrong because I haven't made 100 google APIs [07:28:42] fair enough.. :| [07:32:54] LOL, i added my comment, let's see what comes back [07:38:24] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest. [07:42:26] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [07:53:35] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) left irc: Quit: brb [07:55:48] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Quit: Leaving. [07:57:55] sigh. [07:58:04] mamund: that is a poor response you've been given, imo [07:58:12] and completely misses the previous point about caching [07:58:21] that is EXACTLY what caching is for.. [07:58:26] :| [08:04:38] suprised you agreed with that point mamund [08:04:41] :) [08:15:40] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Quit: bradley-holt [08:24:45] I hate discussions like this because I never know if people think I have a point or I'm just arguing for the sake of it [08:25:03] I can honestly say I actually do believe I am making a valid point [08:25:31] sorry if I'm coming across all Eric'y [08:28:01] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest. [08:29:44] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Quit: Leaving. [08:30:22] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest. [08:30:48] LOL [08:31:09] mikekelly: i, too, think the response is a bit of 'weak sauce' but... [08:31:30] i'd like to hear jg lay out the thinking there w/o too much harping on my end [08:32:08] very interested in what the "value judgments" are for GOOG (i.e. bandwidth, etc.) and seeing how that affects the way they expect client devs and others to bgehave [08:32:27] actually, it's nice that jg is willing to carry on this thread [08:32:34] all valuable stuff, imo. [08:32:44] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest. [08:32:47] right, but afaict it's based on false assumptions about how optmisations hve to be applied [08:32:53] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest. [08:32:55] mikekelly: turn that diagram 90" counter clockwise. [08:32:59] i.e they aren't using caching [08:33:14] KevBurnsJr: ok [08:34:05] CCW or CW ? [08:34:14] makes more sense cw [08:34:30] or I need to swap state and links [08:34:59] yeah I need to rotate 90 CCW and swap the likn and state around [08:35:04] mikekelly: yeah, i totally see your point... [08:35:12] here's something i suspect is in their heads... [08:35:37] "clients stink at honoring caching, we need to 'optimize' that problem out by making the responses as thiny as possible", etc. [08:36:24] perpetuation [08:36:31] cool. [08:36:40] they own a good chunk of the mobile market [08:36:44] they can easily do something about that [08:36:52] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Client Quit [08:37:43] my first time having a proper convo on google+ [08:37:48] it's pretty good [08:37:55] way better than twitter, anyway :) [08:44:58] mikekelly: http://d.kevburnsjr.com/HAL.png [08:44:58] CCW [08:45:16] (I clearly arrived at the office too early this morning) [08:46:05] reason being that when CCW, it more clearly emulates the structure of a HAL doc [08:46:08] in fact.... [09:08:27] I saw something like this in a presentation recently [09:08:28] http://d.kevburnsjr.com/resource_blot.jpg [09:11:31] png also http://d.kevburnsjr.com/resource_blot.png [09:21:45] tomayac_ (~tomayac@213.61.101.1) left irc: Quit: tomayac_ [09:27:35] :o [09:27:51] KevBurnsJr: who gave the presentation ? [09:32:23] huh: https://twitter.com/#!/MTAMMO22 [09:37:07] erm [09:37:12] he seems pretty special [09:58:24] bigbluehat (~bigblueha@adsl-74-177-97-140.gsp.bellsouth.net) joined #rest. [10:28:53] ivanfi (~ivanfi@62.159.77.167) left irc: Quit: Leaving. [11:04:23] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest. [11:05:07] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left #rest. [11:13:21] Guest24321 (~scott@78.129.202.63) got netsplit. [11:13:51] Action: mamund was away [11:14:12] Guest45999 (~scott@78.129.202.63) joined #rest. [11:14:13] mikekelly: wonder if i need to mark my twitter feed as "verified account" [11:24:00] Guest24321 (~scott@78.129.202.63) got lost in the net-split. [12:21:40] mikekelly, KevBurnsJr : i like the idea of representiong a media type in a visual way. [12:22:10] i am soooo "verbal" i don't always think about this POV [12:22:43] and, by *not* thinking about it in a visual way, sometimes have a harder time communicating my ideas. [12:41:26] technoweenie (~technowee@host-86-220-9-69.midco.net) left irc: Remote host closed the connection [13:31:42] rxMokka (~usXr@unaffiliated/rxkaffee) joined #rest. [13:31:48] rxMokka (~usXr@unaffiliated/rxkaffee) left #rest ("WeeChat 0.2.5"). [13:41:48] is there a content type for md5 files? [13:43:19] or what about cryptographic signatures? [13:50:18] there's application/pgp-signature, application/pgp-keys and application/pgp-encrypted at least [14:27:53] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove [14:33:15] bigbluehat (~bigblueha@adsl-74-177-97-140.gsp.bellsouth.net) left irc: Quit: Leaving. [14:54:16] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [15:06:04] mark_burns (~mark@cpc1-dals15-2-0-cust635.hari.cable.virginmedia.com) joined #rest. [15:07:41] Action: steveklabnik waves at mark_burns [15:07:53] hi [15:08:19] so, yeah to continue that conversation. I'm not sure I understand the idea of code-on-demand [15:09:04] it seems to introduce extra coupling [15:09:28] if i was to provide a service then i think i should not enforce a language constraint on the client [15:11:04] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 [15:11:14] for reference [15:12:35] anyway, so yes. it'd add some sort of language constraint onto a client. [15:12:43] that may or may not be worth it [15:13:04] in many cases, it can help with things like scale [15:13:11] since you offload work onto a client [15:13:26] but, clients without the appropriate runtime are screwed. [15:17:00] i think i'm having a hard time understanding what a true REST API (including the HATEOAS constraint) that might be consumed by javascript would be considering that it may also output javascript [15:17:22] Action: mamund was away [15:17:44] Action: steveklabnik waves hello to mamund [15:17:44] i can cope with the idea of abandoning JSON as a communications protocol because it makes the HATEOAS constraint cumbersome [15:17:55] Action: mamund waves back [15:18:42] mark_burns: hmm. why would that be odd? [15:18:45] that'd be the easy case [15:18:52] since you'd have a JS runtime installed for sure [15:19:17] but then parsing XHTML as a javascript client, and also receiving javascript to execute on demand [15:20:11] i'm fine with the concept of a server and client written by the same person/group working hand in hand in the way a complex js web app does [15:21:16] but providing more generic services, that might be consumed by a complex js client that also then receives more js initially is boggling my mind [15:21:23] xhtml is not the only options [15:21:28] option [15:21:54] ok so how do you tackle the forms issue in a universally well understood way? [15:22:01] say for JSON APIs? [15:22:11] you couldnt use json [15:22:15] you'd have to use something like HAL [15:22:17] mark_burns: check out my COllection+JSON for an example [15:22:18] or collection+json [15:22:42] you can define a "form" in any media type/format [15:23:30] mark_burns: does that help? [15:23:47] i mean, is that really what you were asking about [15:23:57] just reading http://amundsen.com/media-types/collection/format/ is that what you mean? [15:24:02] yeah [15:24:16] so i mention that because that design _does_ have something [15:24:22] that mimics HTML.FORM [15:24:48] it's just one design, tho. nothing standard|official|required|etc. [15:25:35] HTML defined a standard for "parameterized transitions" [15:25:55] they use a tag named FORM with sub elements (INPUT,SELECT, TEXTAREA) [15:26:10] mamund: i've been working on a gem to help ruby clients use hypermedia apis, and mark_burns has been messing around with an idea. [15:26:18] and the client is hard-coded to convert that data into a media type (application/x-www-formurlencoded) when sending via POST. [15:26:21] that's all [15:26:24] ahhh [15:26:51] so steveklabnik, do you use the inline (FORM) pattern or the out-of-band (CODE) pattern (ala HAL)? [15:27:23] HAL, Atom both use the out-of-band defintion that clients must hard-code [15:27:26] do you have a link to hal? not sure what to search for [15:27:35] yeah [15:27:54] http://stateless.co/hal_specification.html [15:28:00] thanks [15:28:05] sure [15:28:52] i know HAL has both XML and JSON formats, not sure the status of the JSON one. [15:28:58] XML is registered w/ IANA, tho. [15:29:33] ok so hal only provides support for links? [15:30:05] yeah, like Atom/AtomPub, HAL expects clients to "know" what a valid paylod is ahead of time [15:30:23] my HTML expects clients to figure this out by looking at the response (inline) [15:30:40] my Collection+JSON uses an inline model like HTML [15:30:44] this is a design choice [15:30:54] VoiceXML uses inline, for example [15:32:47] this might also give you some context: http://www.amundsen.com/hypermedia/ [15:33:00] and this: http://amundsen.com/hypermedia/hfactor/ [15:33:26] of course, these are just inventions of mine to create names for common things already existing [15:33:55] mamund: focusing on just xhtml support at the moment [15:33:55] ok i see. it seems like if (in the ruby world) there was a way to represent your resources as either HTML or Collection+JSON quite easily then it could be very useful for writing ruby or javascript clients [15:34:17] mark_burns: yes, that could make the _programmer_ experience easier [15:34:31] steveklabnik: xhtml, gotcha [15:34:44] mamund why the emphasis on programmer? [15:35:02] well, the message on the wire doesn't care _how_ it was created [15:35:06] neither does the server or client [15:35:19] a media type is the "message" passed between parties [15:35:37] well this is what i'm gradually starting to think about. all APIs require some level of human interaction [15:35:47] either out of band communication [15:35:47] if it's "hard" or "easy" to get a client or server to "do that" is not a big deal at runtime [15:35:52] or exploration of an XHTML api [15:36:04] all APIs rely on humans [15:36:18] yeah sure. So it makes sense to make the part that humans have to do easy [15:36:18] either at the instant of execution (human intervention) [15:36:25] that's generally how i think as a rubyist [15:36:32] or at "build-time" (pre-planning) [15:36:40] that's cool [15:36:40] mamund: just messing with ideas, not trying to be all-supporting [15:36:46] LOL [15:37:14] mark_burns: one big problem today is that no framework/coding environment does a good job of [15:37:30] making implementing "hypermedia-oriented designs" easy to do [15:37:40] it would be _waaaaay_ cool if that could happen [15:37:40] that's what i aim to tackle [15:37:43] yep [15:38:02] i suspect ruby esp. has an edge on most other frameworks in this area [15:38:12] as so much of it is about optimizing the programmer experience [15:38:33] yeah. [15:38:43] it's a huge opp. i think [15:38:52] you guys are in the right place for this! [15:38:57] ruby-wise, i mean [15:39:06] :) [15:39:16] i'm trying to strike the balance [15:39:23] between making 100% sure my book is good [15:39:29] and missing this window i feel is happening [15:39:36] yeah. so how i imagine it is like this: [15:39:47] trying to optimize for 'sooner and good enough' but it's difficult [15:40:05] my_business_process = Hateos.new 'api.example.com' [15:40:12] my_business_process.actions [15:40:28] #=> ['sign_in', 'sign_up] [15:40:41] steveklabnik: IMO, you gotta strike while the iron is hot, even if your aim or strength is a bit off [15:40:48] strike now, don't wait [15:40:48] where the actions are dynamic [15:40:58] totally. [15:41:04] mark_burns: my advice on this... [15:41:16] (the programming model for hypermedia that is...) [15:41:34] is to start from the point of the media type, not the events or objects. [15:41:53] start from the place where shared understanding happens [15:41:56] this is not yet done [15:41:59] may be too hard [15:42:08] but i think it's the right approach [15:42:11] well that's where the XHTML thing comes in i think [15:42:19] XHTML is just one media type [15:42:23] so my API consumes the human readable documentation [15:42:29] you can invent more; do new things in any format [15:42:37] but sure, if you want to start there, that's cool. [15:43:01] ok well i'm having enough of a brain melt getting my head around all these new ideas as it is [15:43:06] LOL [15:43:08] you're cool [15:43:10] yeah, i think the 'makes it also human readable' is a great way to present value [15:43:14] to rubyists [15:43:26] and might get them away from their fear of xml ;) [15:43:31] what would a new format be? [15:43:32] wondering if that's the place to _start_ or the place to _end_ _up_ [15:43:49] i was thinking earlier about YAML with serealized Procs (lambdas) for code-on-demand purposes, too [15:43:51] which would be interesting... [15:44:00] mark_burns: i once created a spec for hypermedia CSV [15:44:11] :) [15:44:52] mamund: orly? did you document it anywhere? [15:44:54] mamund so what would you get from that, vs say JSON+collection or XHTML etc? [15:46:11] trygvis: nope, it's laying somewhere in the office, just an experiment really [15:46:38] mark_burns: not sure of your last Q, sorry. can you repeat w/ context? [15:46:40] interresting. we're working with lots of csv data at the current client now [15:46:56] mainly shuffling configuration data (big lists) between an admin server and portal servers [15:47:08] trygvis: i created an added document (also CSV) that described the transitions: a kind of FORMS for CSV [15:47:19] i'll dig it up and email you; might be entertaining [15:47:42] right now we're just reading xls files from disk and serving those, but I'd like to make an admin gui .. something like google spreadsheets [15:47:49] i was experimenting w/ hypermedia controls that appeared in a _separate_ document than the data. [15:48:02] please do, I'd like to see your ideas [15:48:03] this would be interesting for CSV, RDF, etc. [15:48:08] LOL, no problem [15:48:16] might take the weekend to dig up and dust off, tho. [15:48:23] np [15:48:28] :) [15:48:51] mark_burns: did i lose your thread? sorry. [15:49:05] mamund just trying to rephrase [15:49:18] np [15:49:34] i'm trying to get my head around what benefits a csv media type would give you [15:49:36] no formalities here; hack away [15:49:40] ahhh [15:49:48] vs say xhtml [15:49:49] ok, that was really just an experiement [15:50:05] my idea was to see if you could express hypermedia in a secondary doc [15:50:20] also, could you provide clients w/ information on "next steps" on... [15:50:25] possible transitions [15:50:43] even when the format is "data-only" like CSV, RDF, "simple" JSON, etc. [15:50:44] mark_burns: for me it would be a significant reduction in bandwidth and processing time [15:50:59] in the stuff i do... [15:51:01] in a more real world sense, would that be like a spreadsheet with links and forms? [15:51:20] mark_burns: it would be like "pure data" w/ forms attached. [15:51:46] i do work w/ clients that do lots of multi-tenant SaaS implementations. [15:52:03] each customer has special workflow, special fields, special screens, etc. [15:52:25] they accomodate this by using "hypermedia" in responses instead of "hard-coding" client apps [15:52:36] to know what to expect and what to do next. [15:52:41] does that make sense? [15:53:00] the more hypermedia in the response, the less custom code in the client [15:53:09] that's the POV for many of the clients i work w/ [15:53:18] they make more profit if they don't have to recode [15:53:30] yes. one thing that i think i understand more now is the idea of dynamic clients. you can't really get a truly dynamic client [15:53:39] like if you change the del attribute in a link [15:53:44] it breaks the client [15:53:53] if you change the business process you're describing [15:53:55] it breaks the client [15:54:05] yep - you see it [15:54:11] a web browser is an incredibly dynamic client. [15:54:20] but you can at least not specify the exact urls etc [15:54:28] not _have to_ specifiy [15:54:34] so all this yammering about "hypermedia" is a way to try to quantify just what needs to show up in mesages in order to reduce the code in clients [15:54:58] but a web browser is only truly incredibly dynamic because of the human operating it [15:55:06] hmhm, is there a registry of all registered HTTP headers? [15:55:24] I keep on finding gold in existing RFCs, but it would be nice with an index [15:55:26] mark_burns: that particular hypermedia client is designed for a human driver [15:55:36] that's not the only way to do it [15:55:38] mark_burns: i mean in the sense that it can handle an interface for many, many varied applications [15:55:50] HTML is a media type that is custom-built for that particular type of client, too. [15:56:03] that's not the only way to design a media type, either. [15:56:35] steveklabnik yeah sure. mamund so isn't designing a media type out-of-band communication? [15:56:49] yes [15:56:59] the media type is OOB. [15:56:59] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [15:57:13] that's why clients need to "code for the media type" [15:57:27] a meida type is _not_ an application domain [15:57:50] designing a media type is the most powerful way to share understanding between parties. [15:57:54] ok so the media type, and transitions (e.g. rel attributes) are the OOB stuff [15:57:55] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Client Quit [15:58:11] it can be as generic (HTML) or as specific (my MAZE+XML type) as the design wishes [15:58:16] trygvis: this? http://www.iana.org/assignments/message-headers/perm-headers.html [15:58:31] fu-manchu: good catch! [15:59:00] mark_burns: yep, transitions include links and forms (static and dynamic transtions) [15:59:08] For filing under "Media Types -- WTF": http://stackoverflow.com/questions/8144749/rest-api-versioning-when-using-atom-for-resource-collections/8145358#8145358 [15:59:13] and there needs to be a way to "markup" (identify) data in responses. [15:59:32] whartung! you're alive! [15:59:34] :) [15:59:54] "It was the salmon mousse" [16:00:00] ewwwww [16:00:07] :) [16:00:49] steveklabnik so how would you picture 'marking-up' data in a good XHTML API? [16:01:15] depends on what kind of data. [16:01:26] mark_burns, steveklabnik : have you seen "restfulie"? [16:01:31] I like to use <, >, and letters myself. [16:01:34] yeah i have a patch in [16:01:37] actually [16:01:53] i forget why it made me not exactly like it [16:01:55] what do you think of the way they approach this hypermedia thing? [16:01:59] ahh [16:02:01] yeah [16:02:28] it had "legs" for a while, but seems to have stalled; not very popular, i think. [16:02:36] re-reading the README, it seems pretty okay [16:02:44] but a bit too focused on the details. [16:02:48] fu-manchu: nice, thanks! [16:02:49] ahh [16:02:50] especially given ruby's dynamic nature [16:02:55] response = orders.link(payment).follow.post {creditcard => 4444} [16:02:56] i see [16:03:15] should be more like response = orders.payment :creditcard => 4444 [16:03:16] makes some sense (i don't code ruby, so my POV is a bit foggy) [16:03:41] so maybe some poor idioms? [16:03:44] yeah. [16:03:51] understood [16:04:06] it's certainly not _bad_ [16:04:17] have you seen the .NET Web API stuff? [16:04:19] but i'd like to enable people to abstract away the details. [16:04:32] steveklabnik: here's the trick... [16:04:47] no, i stay the hell away from .NET. ;) I occasionally read stuff about it when it seems valuable, ie, MVP, for example [16:04:48] what are "details" to abstract away? and "details" to focus upon? [16:04:54] or MVVM. [16:05:11] steveklabnik: i think they're attempt at doing HTTP well is worth a look. [16:05:14] i don't use it [16:05:20] well, in the previous statement, that the transition is a link, and that we're following it. [16:05:23] but it's got merit, IMO> [16:05:27] totally. [16:05:53] so, here's my sick mind at work.... [16:05:56] i also just don't have many connections to that world, so i dont hear a lot [16:06:07] from my POV, the "details" to focus upon... [16:06:16] are in the media type, no where else. [16:06:26] i want to "code" in media type [16:06:41] steveklabnik i did see that a while ago, but perhaps it was only java when i saw it. [16:06:48] i want a framework that "knows" the media type enough to allow me to simply... [16:06:52] mark_burns: it's been in ruby for the last year or two at least [16:06:57] mamund: hmmm. [16:06:59] mark up states and treansitions and "magic happens" [16:07:04] mamund what does '"code" in media type' mean? [16:07:11] yeah, elaborate a bit [16:07:34] my latency may increase as i'm going to start cooking dinner. i'll make sure to read backlog [16:07:37] consider that i'd want to return a list of "entities" to clients [16:07:50] i'd define that list as a "tremplate" for the media type [16:08:07] Media types aren't rich enough to "code" mamund, semantics aren't deep enough IMHO YMMV GTFO BBQ [16:08:23] i'd want certain transitions to appear in the response (they should be able to sarch, crate new entieis, select one, etc.) [16:08:33] whartung: sez you [16:08:37] sez me [16:08:48] :) [16:08:57] entities != media type [16:09:03] zackly [16:09:10] steveklabnik anyway restfulie looks good. you're suggestion about the api improvements matches my idea too. i think i may co-opt some of restfulie in the hateoas stuff. [16:09:30] you can't safely model with media types either. Imho [16:09:34] i'm going to have to get off. it's getting late in the UK here. thanks for the interesting conversation and insights everyone [16:09:47] mark_burns: great to see you herer [16:09:50] hangout any time [16:10:00] lots of smart folks here [16:10:15] who'd love to hear about what you're doing [16:10:16] ..and me [16:10:20] ROFL [16:10:28] cool i'm sure i'll be back with more questions soon. thanks mamund and steveklabnik. haha. [16:10:38] have fun, no hacking!@ [16:10:39] mark_burns (~mark@cpc1-dals15-2-0-cust635.hari.cable.virginmedia.com) left #rest. [16:11:21] whartung: i still think that "coding in media type" is possible. [16:11:29]