tag:blogger.com,1999:blog-5357647661841035118.post4691214137537398043..comments2023-05-09T02:25:21.999-07:00Comments on A Fundamentalist Restafarian: Please Accept: application/hal+xmlMikehttp://www.blogger.com/profile/16357514742666794260noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-5357647661841035118.post-1179416571412121812010-06-11T05:32:17.436-07:002010-06-11T05:32:17.436-07:00Hi Mike,
@type i see what you mean. The problem wi...Hi Mike,<br />@type i see what you mean. The problem with type is that it means syntax+knowledge. For example imagine a standard for travel business. you could have application/travel+json, application/travel+xml . What i am interested in is the knowledge part. As you say, a client might prefer json over xml. But it needs to know about the semantic to actually do anything with the linked resource. My point is that there has to be some way to hint the client about what it should expect.<br /><br />As for forms, the goal is for complexe paramters that just can't go in the url example.com/myresource/{param}. Mainly for filtering and search related resources. Like Air fare search for example. <br />If it bloats the representation, this might have its place in a response to a HEAD method of the resource.<br /><br /><br />Well for the resource part, don't you think a link in a link looks a bit strange semantically talking ?Redanoreply@blogger.comtag:blogger.com,1999:blog-5357647661841035118.post-66856041783939048952010-06-11T04:53:04.000-07:002010-06-11T04:53:04.000-07:00Hi Reda,
All elements other than <link> are...Hi Reda,<br /><br />All elements other than <link> are intended as example elements that could be contained in a hal representation, these should be established/defined in documentation of the system against the appropriate link relations. So in this example context <title> and <content> would be defined in the documentation for the link relation "item"<br /><br />@type is a possibility, but the current wisdom on its purpose within RESTful applications renders it somewhat meaningless, imo, so I'm leaving it out for now. Client's should express their preferences for media types in the Accept header, and the server can respond with a 406 if it can't provide anything acceptable. Some costs incurred for 'unnecessary' requests, but nothing major.<br /><br />I'm not fond of the idea of a root resource element, it's implicit from the action of dereferencing a URI.<br /><br />I'm also yet to be convinced of the usefulness of forms for machine clients, it bloats the representation and doesn't actually solve the real problems. With forms; machine clients will still have to 'couple' themselves to a fixed assumption of what can be put into the form; if you add inputs into the form a developer will still have to update the machine client to make that happen - at which point why not just communicate the 'form' within the documentation for developers and leave it out of the machine representation?<br /><br />The primary reason HTML forms work so well is that they are aimed at humans, not machines. Human's can make intuitive decisions based on graphical and natural language clues/inference - this is something that machines just do not do right now. I don't think that distinction should be taken for granted! :)Mikehttps://www.blogger.com/profile/16357514742666794260noreply@blogger.comtag:blogger.com,1999:blog-5357647661841035118.post-52114740650753767622010-06-11T03:50:56.615-07:002010-06-11T03:50:56.615-07:00Hi @mamund! :)
"if @name must be unique in a...Hi @mamund! :)<br /><br />"if @name must be unique in a set (same @rel), why not use @id instead?" - to avoid confusion with uniqueness of @id html <br /><br />"is @rel only a 'group name'? IOW, is it an object like 'list'? if yes, are things such as @rel="edit" not valid w/ hal?" - I wouldn't say not valid, just not (imo) good practice. They're still just resources.<br /><br />"can @rel be a whitespace separated list of values? (@rel='item edit')" - yes<br /><br />"for easy access via machine processing consider using using elements to outline content in a link" - do the data elements need to be generic in that way? What does the system gain from that?<br /><br />"What about query templates (FORM method="get")?" - no need because you can use URI templates for that<br /><br />"write templates (FORM method="post|put|delete")?" - machine client's don't need write templates/forms, they should be written against the latest definition for the link rel in question, that is contained in the system's documentation.Mikehttps://www.blogger.com/profile/16357514742666794260noreply@blogger.comtag:blogger.com,1999:blog-5357647661841035118.post-21170648187670174872010-06-11T03:03:32.076-07:002010-06-11T03:03:32.076-07:00I've asked a question about this same thing on...I've asked a question about this same thing on stackoverflow (http://stackoverflow.com/questions/3014016/on-rest-wadl-or-not-idl-is-the-following-approach-right), Darel Miller pointed me to your post. <br />I like this idea ! One thing i'd add is a resource element and a type attribute on the link element. The latter would make it easy for the client to know in advanced if it can deal with the linked resource.<br />The resource element would be the abstract representation of any resource. I'd use that as the root of your document (instead of link).<br />As for "title" and "content", do you think these are useful to machines ?<br />An other thing i have been thinking about for links that modify a resource (POST or PUT) is to have something similar to forms and it seems mamund has bought up this question. Basically this would be something about including a structure inside link for the client to know how the server expects the input.<br />Great to know that a lot of people are interested in such a thing. Actually REST defines abstract concepts and it sure would be great if it defined an implementation of these abstract concepts.Redanoreply@blogger.comtag:blogger.com,1999:blog-5357647661841035118.post-83214388269664924492010-06-10T07:53:58.080-07:002010-06-10T07:53:58.080-07:00As you might suspect, I like this idea.
some sugg...As you might suspect, I like this idea.<br /><br />some suggestions:<br /><br />if @name must be unique in a set (same @rel), why not use @id instead?<br /><br />is @rel only a "group name"? IOW, is it an object like "list"? if yes, are things such as @rel="edit" not valid w/ hal? <br /><br />can @rel be a whitespace separated list of values? (@rel="item edit")<br /><br />for easy access via machine processing consider using using elements to outline content in a link:<br />[link]<br />[data id="name"]...[/data]<br />[data id="age"]...[/data]<br />[/link]<br />What about query templates (FORM method="get")? and write templates (FORM method="post|put|delete")?mamundhttp://amundsen.com/blog/noreply@blogger.comtag:blogger.com,1999:blog-5357647661841035118.post-46563629759295848252010-06-09T09:24:12.348-07:002010-06-09T09:24:12.348-07:00Personally, I think this is bad, because with this...Personally, I think this is bad, because with this the <link> element has suddenly become ambigious and all the meaning is then pushed to the attributes and containment relationship of elements. Also, it's very difficult to read.<br /><br />As your question asks, to me, it does in fact look a lot like RDF/XML.Rajeev J Sebastianhttp://www.rajeevsebastian.comnoreply@blogger.comtag:blogger.com,1999:blog-5357647661841035118.post-44498869218932866972010-06-08T23:58:24.511-07:002010-06-08T23:58:24.511-07:00Addendum: application/hal should be application/ha...Addendum: application/hal should be application/hal+xml of course.Thomas Steinerhttp://blog.tomayac.comnoreply@blogger.comtag:blogger.com,1999:blog-5357647661841035118.post-68827241281793143042010-06-08T23:55:59.902-07:002010-06-08T23:55:59.902-07:00Hi Mike,
IMHO you did not reinvent RDF/XML, but a...Hi Mike,<br /><br />IMHO you did not reinvent RDF/XML, but a bit of Atom and a bit of standardization of what @mamund describes here: http://www.amundsen.com/blog/archives/1041 ("bit" not in a negative sense). Will it (application/hal) make our lives easier? Maybe, if everyone implements it. I think getting media type documentation right (so that people know what to expect [and thus not have the need for a @method={GET|POST|PUT|DELETE|PATCH} attribute that some (including me) have been thinking of]) is way more important. This, plus a reliable (i.e. semantically well defined) set of values for the @rel attribute could already be good enough.<br /><br />Cheers,<br />Tom<br />@tomayacThomas Steinerhttp://blog.tomayac.comnoreply@blogger.com