2011 03 16 IRC Meeting log

[16:57] <lsmith> so everybody ready to talk REST?
[16:58] <aways|bnc> Good meeting And good night :P
[16:58] ← lapistano left IRC. (Excess Flood)
[16:58] → lapistano joined the channel.
[17:00] <pgodel_work> here
[17:00] <rande> here too
[17:00] → davidcoallier joined the channel.
[17:00] <lsmith> good good
[17:00] <avalanche123> hi
[17:00] <lsmith> soo
[17:00] <davidcoallier> Haya :)
[17:00] <pgodel_work> hi
[17:00] <kertz> hi
[17:01] <lsmith> as i stated on twitter .. i am not a REST guru .. but i am starting to understand why its cool
[17:01] <lsmith> especially in light of ESI
[17:01] <kertz> I don't even know why it's cool! :p
[17:01] <lsmith> so being the talkative type i am .. i started talking to people
[17:01] <lsmith> and wrote down my findings on https://github.com/liip/ViewBundle/wiki
[17:01] → _orso_ joined the channel.
[17:01] <lsmith> to some extend i am mixing the topic of format agnostic controllers with REST
[17:02] <lsmith> but that seems ok .. since other people do that too :)
[17:02] <pgodel_work> yes
[17:02] <lsmith> for example FRAPI also supports different output formats
[17:02] <lsmith> speaking of FRAPI .. we have a special guest .. davidcoallier :)
[17:02] • davidcoallier hdies
[17:02] <davidcoallier> *hides
[17:02] <lsmith> http://getfrapi.com/
[17:02] → chirimoya joined the channel.
[17:02] <lsmith> now in terms of what we have in Symfony2 atm
[17:02] <davidcoallier> I'm merely lurking and listening in remember :)
[17:03] <lsmith> there is the EverzetRestfulControllersBundle
[17:03] <lsmith> which makes it really easy to build RESTful controllers .. since it automates the route generation
[17:03] → tyx joined the channel.
[17:03] <lsmith> and also enforces sort of a naming convention
[17:03] → mahono joined the channel.
[17:03] <lsmith> to some extend FrameworkExtraBundle could be the basis for similar solutions
[17:04] <lsmith> or rather i am sure it could be helpful
[17:04] <lsmith> to enable annotations in this entire mix
[17:04] <lsmith> to make development easier for simple REST API's
[17:04] <lsmith> and finally there is https://github.com/liip/ViewBundle
[17:04] → t3rob joined the channel.
[17:04] ← krymen left IRC. (Quit: Leaving.)
[17:04] <lsmith> which adds a "proper" view layer between Controllers and templates (to the point where templates become optional)
[17:05] → cpnfortehwin joined the channel.
[17:05] <lsmith> oh and i should also mention that the view bundle is heavily based on the Serializer component https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Serializer
[17:05] <pgodel_work> which I am really looking forward to start using :)
[17:05] <lsmith> the job of the Serializer component is to take some data and turn that into some output format and back
[17:05] <lsmith> one of the key features there are normalizers
[17:06] <lsmith> they can take an class instance and convert it to an array and back
[17:06] <lsmith> so far so good
[17:06] → bbieber joined the channel.
[17:06] → nsolsen joined the channel.
[17:06] → ChristianMueller joined the channel.
[17:06] <lsmith> for one i think the entire experience could be more polished with the tools we already have
[17:06] <pgodel_work> so it appears that at least, Symfony2 native, there would be 3 ways to building RESTful api
[17:07] <lsmith> but i also think we are still missing stuff
[17:07] <avalanche123> the hardest part would be to deserialize request body
[17:07] <lsmith> pgodel_work: well actually the viewbundle and the restfulcontroller bundle play together
[17:07] <rande> how do you standardize the output format ?
[17:07] → DolbyDB joined the channel.
[17:07] <lsmith> and frameworkbundle could be integrated with the viewbundle to some extend
[17:08] <lsmith> rande: for the output format the viewbundle basically proposes a concept where you "configure" a view bundle
[17:08] <lsmith> you tell it to redirect or a template name and parameters
[17:08] <lsmith> and the view bundle then lets you interpret those configurations differently for each format
[17:08] <lsmith> so you might ignore the template for json/xml
[17:09] ← vjousse left IRC. (Quit: Quitte)
[17:09] <lsmith> or you might render the template in html and embedd it into a json response etc
[17:09] <lsmith> the key is that for the output via the Serializer component everything is first converted into arrays
[17:09] <rande> if I want to ouput a Form in xml
[17:10] <rande> should I use by own convention or use a standard (xform) ?
[17:10] <lsmith> rande: right .. so the idea to output a Form in XML would be to generate some format that advertises an API
[17:10] <rande> format + standard
[17:11] <lsmith> there can be many serialization formats to render a form
[17:11] <lsmith> like html form tags, wsdl for soap, json-schema for json, wadl for xml etc
[17:11] → johnkary joined the channel.
[17:12] <rande> soap is not restful ?
[17:12] → hlubek joined the channel.
[17:12] <lsmith> so really when you want to add a ressource in an html app there are a couple of steps not all of which make sense in all cases
[17:12] <lsmith> rande: like i said .. i am mixing the topic of format agnostic a bit with REST
[17:13] <lsmith> but of course we do not have to do that
[17:13] <lsmith> 1) list the current resources
[17:13] <lsmith> 2) ask how to create a new resource
[17:13] → wissl joined the channel.
[17:13] <lsmith> 3) post the new resource
[17:13] <lsmith> -> handle error or -> redirect to the newly created resource
[17:13] → Dator joined the channel.
[17:13] ← Dator left the channel.
[17:13] <lsmith> 4) view a resource
[17:13] → Dator joined the channel.
[17:14] <lsmith> i think 2) is often skipped in REST API's
[17:14] <lsmith> correct?
[17:14] <lsmith> but of course is necessary for HTML interfaces
[17:14] <lsmith> aka you need to render a form to let the user enter data
[17:14] <lsmith> but usually if all you want to provide is a way for users to submit a POST via json
[17:14] <pgodel_work> right, it is not skipped, but handled by something else
[17:15] ← Dator left IRC. (Client Quit)
[17:15] <lsmith> yeah .. you might generate some documentation
[17:15] <lsmith> like FRAPI does
[17:15] → Herzult joined the channel.
[17:15] <mahono> yes, in REST APIs there is some sort of specification so 2) ist not required
[17:15] → M00nShield joined the channel.
[17:15] <lsmith> just some random doc page davidcoallier mentioned in #frapi today http://frapi-new-docs-style.orchestra.io/
[17:15] ← hlubek left IRC. (Quit: Leaving.)
[17:15] → hlubek- joined the channel.
[17:15] • hlubek- is now known as hlubek.
[17:15] <mahono> ..or documentation
[17:16] <lsmith> let be briefly go through the things i currently see missing
[17:16] <davidcoallier> Sorry was on the phone.
[17:16] <lsmith> and maybe we can complete that list
[17:16] <lsmith> "explore making it possible to to configure which RedirectResponse class to use for each format"
[17:16] → fentie joined the channel.
[17:16] <kriswallsmith> lsmith: sounds like a case for a response factory
[17:16] <lsmith> mainly what i am talking about here is that when in an html interface you "redirect" after a POST
[17:17] <lsmith> you would maybe want to return OK in json
[17:17] <lsmith> or the url to the new resources
[17:17] <lsmith> or return the content for the new resource (and use pushState in the browser to update the url)
[17:17] <lsmith> kriswallsmith: maybe
[17:17] <kriswallsmith> or maybe not :)
[17:17] ← jakubzalas left IRC. (Read error: Connection reset by peer)
[17:18] <lsmith> the next thing is about 2) .. which imho isnt super important
[17:18] <lsmith> "implement a normalizer for form's to automatically advertise an API via WSDL, RDFa, JSON-Schema and that returns a list of errors if instead if the form has any validation errors associated"
[17:18] → jakubzalas joined the channel.
[17:18] ← jakubzalas left the channel.
[17:18] <lsmith> the next thing is about how to best handle errors in POSTs (aka resource creation)
[17:18] <lsmith> figure out how to best set a proper HTTP status code when outputting a form with validation errors for each format
[17:19] <lsmith> the next item is mostly about bringing the various bundles together .. aka FrameworkExtra, EverzetRestfulControllers and View Bundle
[17:19] <pgodel_work> yes, that seems to be quite important to have one implementation
[17:19] ← skoop left IRC. (Remote host closed the connection)
[17:19] <lsmith> another topic could be to try and become compatible with FRAPI .. maybe even make it optionally possible for FRAPI to generate Symfony2 code
[17:20] <pgodel_work> or way of doing things
[17:20] <lsmith> finally and this might be a topic we can best discuss today:
[17:20] <kriswallsmith> lsmith: the form wsdl mechanism could also export to a filter definition
[17:20] <kriswallsmith> some sort of form dumper
[17:20] <lsmith> "auto-deserialize request body and based on request content-type" and "accept header support"
[17:20] <lsmith> kriswallsmith: the form dumper would be a normalizer
[17:20] <lsmith> aka you pass an instance of a form object to the serializer
[17:21] <lsmith> the serializer picks the proper normalizer for form objects
[17:21] <lsmith> and turns the form into an array
[17:21] <lsmith> <lsmith> "auto-deserialize request body and based on request content-type" and "accept header support" <- i am a bit clueless on this topic
[17:22] <lsmith> oh i forgot another topic .. API versioning
[17:22] <lsmith> which possibly also fits into that topic
[17:22] <lsmith> since i guess one can version API's either via URL's or via headers ..
[17:23] <lsmith> http://www.informit.com/articles/article.aspx?p=1566460
[17:23] <davidcoallier> headers
[17:23] <davidcoallier> Always headers.
[17:24] <davidcoallier> URLs should be self-describing collections and resources.
[17:24] ← dbu left IRC. (Remote host closed the connection)
[17:24] <rande> also, how do you plan to define how dynamic field are loaded ?
[17:24] <davidcoallier> By inserting non-standard versions in the URL, it breaks the actual representaion.
[17:24] <lsmith> davidcoallier: i agree .. but mostly because i find versions in URLs ugly to look at :)
[17:24] <rande> this cannot be done by this definition
[17:24] <lsmith> rande: what do you mean with dynamic fields?
[17:24] <rande> so you need other controller to deal with that
[17:24] <kertz> davidcoallier: +1
[17:24] <rande> autocomplete for instance
[17:25] <DolbyDB> embedded 1 to many related entities as well?
[17:25] <lsmith> well this is a HTML interface challenge .. now the HTML interface could in turn query a REST API via JSON
[17:25] <lsmith> that returns a list
[17:26] <lsmith> in that sense you have a form widget that integrates the autocomplete code
[17:26] <lsmith> but that autocomplete code would then just use a fairly straight forward REST GET call to get a list of resources with some filter
[17:26] ← cpnfortehwin left IRC. (Quit: Page closed)
[17:27] <lsmith> i guess the filter would be a GET parameter?
[17:27] <davidcoallier> Also consider you have to handle content-types.
[17:27] <lsmith> aka .. group/list?filter=foo
[17:27] <davidcoallier> like
[17:27] <rande> yep
[17:27] <davidcoallier> curl -X POST http://url -d '{"key":"value"}' -H 'Content-Type: application/json'
[17:27] <davidcoallier> for instance.
[17:27] <rande> another issue is : does all format offer the same set of features ?
[17:28] <lsmith> rande: well in general "yes"
[17:28] <rande> ;)
[17:28] <lsmith> though for HTML the experience would be quite different
[17:28] <lsmith> for example
[17:28] <lsmith> 1) HTML usually will use templates, most other formats will not
[17:28] ← ralf57 left IRC. (Quit: Leaving)
[17:29] <lsmith> 2) HTML will usually want to be forced to redirect other formats you will probably at most inform about the url to redirect to
[17:29] <lsmith> but for most non HTML formats .. i would expect the experience to be very similar .. with the exception of the case 2) (aka advertising the API)
[17:29] <lsmith> agreed?
[17:30] <lsmith> now one of the big questions i still have is how does a REST specify the format?
[17:30] <lsmith> i guess the format in which the rest is made is defined via the Content-Type
[17:31] <lsmith> and the output format via Accept header or a "file" extension
[17:31] <lsmith> ?
[17:31] <pgodel_work> I think that is correct
[17:32] <davidcoallier> That's it.
[17:32] <davidcoallier> Some do Accept both ways, some do content-type both ways.j
[17:32] <kertz> but maybe we should stick to a standard?
[17:32] <M00nShield> lsmith,  we coul see how some rest services are doing it  no?
[17:33] <lsmith> well the simplest is that we assume that the format you request is also the format you used in your request content
[17:33] <lsmith> how important is accept header support?
[17:33] <pgodel_work> not much to me
[17:33] <pgodel_work> I like using the file extension to define it
[17:33] <lsmith> how important is "auto-deserialize request body and based on request content-type" ?
[17:33] <davidcoallier> Very if you want to call it RESTful
[17:34] <lsmith> davidcoallier: ok .. because otherwise you have different URLs for the same content (just in different formats)
[17:34] <pgodel_work> but I can see what david implies
[17:34] <lsmith> ?
[17:34] <davidcoallier> lsmith: essentially yeah.
[17:35] <davidcoallier> And asking for a complex format through an URL is quite hard ;)
[17:35] <lsmith> kriswallsmith: do you have an idea how hard it would be to add accept header support as well as being able to do content type specific request body deserialization?
[17:35] <pgodel_work> davidcoallier: what would be an example of a complex format ?
[17:36] <davidcoallier> pgodel_work: Accept:application/xml,text/json,application/json+xml;q=0.9,*/*
[17:36] <kriswallsmith> lsmith: easy -- use core.request
[17:37] <lsmith> ok
[17:37] <lsmith> and this also where we could read an API version out of the headers
[17:37] <davidcoallier> pgodel_work: what if you have to represent say a resource and you accept silverlight and silverlight-2-b2
[17:37] ← fabpot left IRC. (Quit: fabpot)
[17:37] <pgodel_work> davidcoallier: interesting
[17:38] <pgodel_work> so the server sends all possible variations ?
[17:38] <lsmith> ok .. so we need a core.request listener to handle all the decoding
[17:39] <kriswallsmith> pgodel_work: the best match
[17:39] <pgodel_work> how would the server know which one is the best match ? first on the list ?
[17:39] <davidcoallier> pgodel_work: URI-specified representation is perfectly valid, but there are more headers to Accept than only the format.
[17:39] → mapi joined the channel.
[17:39] <lsmith> what about error handling?
[17:39] <davidcoallier> Encoding, language, etc.
[17:40] <pgodel_work> right
[17:40] <lsmith> we have a related pull on the topic of error handling https://github.com/symfony/symfony/pull/128
[17:40] <lsmith> for form submission .. i guess for listing POST data validation errors lets say in xml or json
[17:40] <lsmith> there is no standard for that .. right?
[17:40] <lsmith> i mean obviously you set the appropriate status code in the response
[17:40] <lsmith> but for the actual errors
[17:41] <lsmith> you probably should support returning a string and a code for each error
[17:41] <lsmith> and thats it
[17:41] <lsmith> nothing fancy
[17:41] <lsmith> ?
[17:41] <pgodel_work> that's what we do in our api, not sure if it is the right way :)
[17:42] <pgodel_work> but it works
[17:42] <M00nShield> lsmith, i think it's for api developpers to define their own errors codes
[17:42] <lsmith> M00nShield: yes of course
[17:42] <kriswallsmith> pgodel_work: see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
[17:43] ← chirimoya left IRC. (Remote host closed the connection)
[17:43] → chirimoya joined the channel.
[17:43] <pgodel_work> ok, so this is based ont he HTTP spec. nothing specific to REST
[17:44] <kriswallsmith> yeah
[17:45] ← mapi left IRC. (Ping timeout: 246 seconds)
[17:45] <lsmith> ok .. i have learned a fair bit so far and hopefully others have learned about what we currently have available
[17:45] → carlossg_00 joined the channel.
[17:46] <lsmith> now one concrete task i see is developing a core.request listener to decode RESTful request headers and content
[17:46] <pgodel_work> that would be nice
[17:46] → mtotheikle joined the channel.
[17:47] <lsmith> another one could be working on a form normalizer mainly for outputting form validation errors
[17:47] <lsmith> not necessary for normalizing form rendering itself (which might be nice to have .. but doesnt seem so important)
[17:47] <lsmith> and the last one is integration the view, frameworkextra and restfulcontrollers bundles
[17:48] <lsmith> is there anyone interested in taking on any of these tasks?
[17:48] <lsmith> btw shall we assume FRAPI to be sort of a "role model" for us?
[17:48] <lsmith> FRAPI seems quite easy to use an get started
[17:48] <M00nShield> excuse my ignorance but how do we use forms with restful webservice?
[17:48] <lsmith> there is a nice screencast
[17:48] <pgodel_work> sounds like they have done their homework :)
[17:48] <lsmith> M00nShield: so the idea with "forms" and RESTful services is as follows
[17:49] <lsmith> there is this step 2) (aka rendering the form aka advertising the API) which would be handled by a normalizer specifically for form objects
[17:49] <pgodel_work> I think I need to play around with those bundles to understand more how the would play together
[17:49] <lsmith> that normalizer would only be triggered for non HTML output
[17:49] <lsmith> for HTML output this task would be delegated to the template
[17:50] <lsmith> for validation errors .. like i said there would again need to be a normalizer (actually it would need to be the same normalizer that detects if the form has been validated .. aka a POST has happened and not a GET on the API description)
[17:51] <lsmith> and then on a successful form submission we need to handle the redirect .. here the plan seems to likely include using a Response factory.
[17:51] → henrikbjorn joined the channel.
[17:51] <lsmith> M00nShield: does that make things clearer?
[17:52] <M00nShield> i thought we could ignore the usage of forms with restful webservice and send directly the data via POST or get
[17:52] <lsmith> i will add a list of all the common REST requests (list, show, request API, create/edit, delete)
[17:52] <lsmith> and what components do what there
[17:52] <lsmith> M00nShield: right ..
[17:52] <M00nShield> so what's the point of using forms
[17:52] <lsmith> but on the server there would still be an instance of the form component
[17:52] <pgodel_work> M00nShield: using forms is not required for REST, this is just an option if you want to REST-enable your forms
[17:52] <M00nShield> validation?
[17:52] <lsmith> that processes the form
[17:53] <M00nShield> ah okay
[17:53] <M00nShield> sorry then
[17:53] <lsmith> M00nShield: validation ..
[17:53] <johnwards> oh sorry folks missed the meeting!
[17:53] <lsmith> ok .. anyone interested in stepping up for any of the tasks i just mentioned?
[17:53] <M00nShield> the cleverage guys talked about validating data without forms in symfony 2
[17:54] <lsmith> M00nShield: its possible to do so quite easily
[17:54] <lsmith> however if we want to have the same code to handle both HTML as well as JSON, XML etc
[17:55] <johnwards> lsmith: I might be interested in lots of things but I'm now an hour behind. I am about to leave the office for the day but I have a copy of the last hours messages.
[17:55] <lsmith> you kind of already have the form instance .. and unless you want to do if/else handling in your controllers for different formats
[17:55] <lsmith> you might as well just create the form
[17:55] <lsmith> we will need to make sure it doesnt add all too much overhead
[17:56] <lsmith> hmm not many hands going up
[17:56] <lsmith> so i guess i will just try to organize the things i learned today
[17:56] <pgodel_work> as I said, I need to get more familiar with the bundles :)
[17:56] <lsmith> and update the wiki accordingly
[17:57] <lsmith> once i am done i will post something on twitter
[17:57] <M00nShield> I would like to some stuff but things are still not enough clear for me :)
[17:57] → phidah joined the channel.
[17:57] <lsmith> M00nShield: ok good to hear you are interested
[17:57] <pgodel_work> I think it was very useful the meeting
[17:57] <lsmith> so lets try and make things clearer :)
[17:57] ← old_sound left IRC. (Ping timeout: 255 seconds)
[17:58] <lsmith> M00nShield: do you have a concrete question i can answer?
[17:58] <lsmith> or is it just a general feeling of being unsure how the various pieces fit together?
[17:58] <M00nShield> humm actually a lot
[17:58] → kamilente joined the channel.
[17:58] → mapi joined the channel.
[17:58] <M00nShield> lsmith exactly
```plain
[17:59] <M00nShield> like you siad
[17:59] <M00nShield> said*
[17:59] <lsmith> ok .. i will try to make this clearer in my next update of the wiki page
[17:59] <M00nShield> i don't get the whole picture
[17:59] <M00nShield> great
[17:59] <M00nShield> can't wait
[17:59] <lsmith> i will try to list all common REST request types
[18:00] <lsmith> and what each already existing or not yet existing component does for each request type
[18:00] <mtotheikle> Can you send link to wiki please?
[18:00] <lsmith> mtotheikle: https://github.com/liip/ViewBundle/wiki
[18:00] <M00nShield> yes please I was about to ask the same thing
[18:00] <mtotheikle> Thanks
[18:00] <lsmith> i will also place a link to the logs from this meeting there
[18:00] ← carlossg_00 left IRC. (Quit: Page closed)
[18:00] <lsmith> so .. its 6:00PM ..
[18:01] <lsmith> so i hereby call the meeting over ..
[18:01] <lsmith> unless someone has something important?
[18:01] <M00nShield> \o/