http://blog.gmane.org/gmane.comp.web.services.rest hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.web.services.rest/16010 <pre>I don´t know, if i´m the only one, but isn´t the yahoo groups webpage a little bit annoying? 1. Reply: When you click reply, the messages sender is always the default recipient. Hellloo? it is a group discussion, what should be the default here? Or why not provide at least a "reply all" link? I don´t know how many double posts i received (and sent!) because of that "feature". 2. Help/Feedback: Ever tried to provide feedback to yahoo? Have fun! I was clicking around for 10 minutes until i found something, where i could phrase a question, just to discover, that the FAQ was searched by this phrase. Nice... 3. Design: I don´t know, where to start. Maybe the two search fields? All these little (un)information canapés spread over every page? The layout from the 90ies? In a nutshell: These "affordances" make me think to much for a simple discuss group application. Had to be said... </pre> Jakob Strauch 2012-05-05T08:31:07 http://comments.gmane.org/gmane.comp.web.services.rest/16000 <pre>Hi, admittedly I completely missed the existence of RTSP[1]. It is a massive spec, sort of a redefined 2616 and stuff on top. I am trying the shortcut here: has anyone ever looked at it an has thoughts whether it is a particularly good or particularly bad example of protocol design? There is, for example stuff like a SET_PROPERTY method which surely should have been PUT /foo/&lt;property&gt; :-) Jan [1] http://tools.ietf.org/html/rfc2326</pre> Jan Algermissen 2012-04-26T16:58:00 http://comments.gmane.org/gmane.comp.web.services.rest/15996 <pre>For example, suppose I pass an invalid argument (a -ve quantity of a product when placing an order, say)... what response is appropriate? One suggestion I've seen is 422 (unprocessable entity)... which appeals because it talks about semantic error as opposed to a syntactic error (which is what I see 400 as). Agree? disagree? other suggestions? Thx Dan </pre> Dan 2012-04-17T06:28:12 http://comments.gmane.org/gmane.comp.web.services.rest/15985 <pre>If I'm using If-Match with ETag as a way of implementing optimistic locking (which I guess is a pretty standard approach), then should 409 or 412 be used to indicate that an optimistic locking problem. According to [1] and [2], both seem to fit. I presume there's a subtlety or two I'm missing? Thx Dan [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html [2] http://www.webdav.org/specs/rfc4918.html#rfc.section.12.1 409: Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type. [1] 412: Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or th</pre> Dan 2012-04-15T16:36:32 http://comments.gmane.org/gmane.comp.web.services.rest/15969 <pre>Hi, We are working on a REST API for the server-side of a graphical modeling platform. Our resources - models, diagrams and elements - are hierarchical by nature and our server keeps track of revisions of these models. The platform allows users to work on the same models simultaneous. Concurrency is realized using a git-inspired strategy; when a user starts working, he starts working on a new revision that is not yet shared with others. The unshared update a user is working on, does reside on the server, so the user can close his session and continue later wihout having to share his changes. As a user's work evolves, the system claims the resources he touches, making sure he can effectuate his changes at a later point in time. This pessimistic approach appears to fit our customers the best. Of course claims have a time-out to avoid dead-lock and/or starvation. To expose the functions that we support in a RESTful way, we came up with a two-phase-commit-pattern we like to refer to as the 'framing the futur</pre> Diederik 2012-04-11T15:51:10 http://comments.gmane.org/gmane.comp.web.services.rest/15967 <pre>Hi! I'm wondering about RFC 5988, which says very little about how to process links other than the word "dereference" (4 times) which might imply using a safe method to GET something. Are Link: headers and &lt;atom:link&gt; elements primarily designed to support navigation using safe methods? Are there any link relations out there that have processing instructions that say "POST to me to do this" or something similarly unsafe? I'm only aware of atom's "edit" link relation, which says something about GET and PUT, but that's the exception, and in any case you typically start by GET'ing it anyway, so you're still dereferencing the link. Atom uses the &lt;app:collection&gt; element to indicate that you can POST entries to a collection; HTML uses the &lt;form&gt; element... Again, shunning links when it comes to "unsafety". Are links inherently meant to be safe links? RFC 4287 says &lt;http://tools.ietf.org/html/rfc4287#section-4.2.7.2&gt;: "The value of "rel" describes the meaning of the link, but does not impose any behavioral</pre> Erik Mogensen 2012-04-11T02:20:30 http://comments.gmane.org/gmane.comp.web.services.rest/15950 <pre>Hi All. A couple of days ago DeveloperFusion published an article of mine that is the first part of an idea about evaluation of REST Frameworks. That is the first part, where we simply explain as quickly as we can what REST is, then make a list of what a REST APP may require, and then we made up a maturity model for frameworks based on how much support for achieving those requirements they offer. Any feedback is appreciated, as the model idea may benefit a lot from fresh views. I publicly thank Glenn Block for his insight and ideas in the article. So that is the first part of my request here, I know you all may have something to comment :D The second part of my request is regarding the second part of the article: After we have the model, we need to provide an evaluation of the current frameworks! That evaluation I did long ago and without the model. Now, I do not use all the frameworks of course, so it will be great if some of you may take a look at the model, then review the framework you most work with </pre> William Martinez Pomares 2012-04-06T16:09:34 http://comments.gmane.org/gmane.comp.web.services.rest/15938 <pre>Back in december 2009 I asked for some feedback on the implementation of a generic REST client library in C# (http://tech.groups.yahoo.com/group/rest-discuss/message/14110). I got some valuable feedback then and during the last three years I have been working on and off on something - and now, at last, it is stable and ready for use by any one who are consuming REST services in C#. It is already in use at the company I work for (www.cbrain.com) where I am implementing a REST service for our case management system. Here Ramone is used to simplify the automated test code, and also in some internal integration service that moves data to and from another sub-system. I have blogged a few pieces about the library here: http://soabits.blogspot.com/2012/04/consuming-web-apis-in-c-with-ramone.html, http://soabits.blogspot.com/2012/04/introducing-ramone-c-library-for-web.html and http://soabits.blogspot.com/2012/04/ramone-consuming-hyper-media-rest.html. The code is released at Github, https://github.co</pre> Jørn Wildt 2012-04-04T22:33:12 http://comments.gmane.org/gmane.comp.web.services.rest/15890 <pre>It seems like there is an ongoing debate/mismatch/battle/whatever between REST and Linked Data (if I am interpreting various Tweets correct). Could anyone share a link to something that can enlighten me on what this is about? Thanks, Jørn </pre> Jorn Wildt 2012-04-03T08:29:33 http://comments.gmane.org/gmane.comp.web.services.rest/15884 <pre>I'm about to build a web app that should expose its functionality via API and I'm trying to find the most effective way to do that and would like to hear your thoughts on the topic. The functionality of the 'website' and the API intersect, with API having additional features that should not be available from the website (from browser). A traditional approach to building such systems seems to be building a website and an API as two separate projects, probably even using different technologies. That seems ineffective as there are 2 places (website and api) which have to invoke the same business logic with all the joys as a result. For example, adding a feature that should be exposed in both requires adding it to 2 places. Basically you should always think about keeping your website and API in sync. Not fun. And I don't want to have browsers and machine clients to work with the same html as it can easily become too verbose. Another way is to have the same set of resources that a browser and programmatic clien</pre> Vitaly Stakhov 2012-04-02T19:07:44 http://comments.gmane.org/gmane.comp.web.services.rest/15882 <pre>Hi REST people, Some simple questions that might lead to interesting discussions: How far do you agree that REST and hypermedia are about following one’s nose? Is the “following your nose” thing an essential part of REST? And what is there more to REST than can be explained by “following your nose”? All input welcome! Best, Ruben PS This post was inspired by Erik Wilde’s blogpost about describing REST – http://dret.typepad.com/dretblog/2012/03/rest-layers.html ------------------------------------ Yahoo! Groups Links &lt;*&gt; To visit your group on the web, go to: http://groups.yahoo.com/group/rest-discuss/ &lt;*&gt; Your email settings: Individual Email | Traditional &lt;*&gt; To change settings online go to: http://groups.yahoo.com/group/rest-discuss/join (Yahoo! ID required) &lt;*&gt; To change settings via email: rest-discuss-digest&lt; at &gt;yahoogroups.com rest-discuss-fullfeatured&lt; at &gt;yahoogroups.com &lt;*&gt; To unsubscribe from this group, send an email to: rest-discuss-unsubscribe&lt; at &gt;yahoo</pre> Ruben Verborgh 2012-04-02T10:44:30 http://comments.gmane.org/gmane.comp.web.services.rest/15879 <pre>hello. "The 'profile' Link Relation Type" http://www.ietf.org/id/draft-wilde-profile-link-00.txt is now officially published as an I-D. it is the version that i made available on my server a little earlier, and some comments were already posted here earlier this month http://tech.groups.yahoo.com/group/rest-discuss/message/18578 . additional comments are very welcome, and i plan to publish a new version (incoporating the previous rest-discuss comments and any new ones) as soon as possible. thanks a lot and cheers, dret. </pre> Erik Wilde 2012-03-26T10:04:46 http://comments.gmane.org/gmane.comp.web.services.rest/15875 <pre>Folks, I've defined a read only API where links to other resources follow an Atom like model and include the media-type &amp; relation as well as the URI, so they look something like this in JSON: links: [ { href: "/foo", type: "fooType", rel: "self" }, { href: "/bar", type: "barType", rel: "http://example.com/customeRel" ] In a conversation with someone who is not entirely into the whole REST thing they commented "including the type &amp; relation in the link is extra complexity, if we did it in XML we could just figure that out implicitly from the schema when we GET the linked resource" Leaving aside XML Vs JSON arguments (which aren't relevant to my question) I justified it with an argument that explicitly including the relation meant you didn't need to GET the resource to know what the relationship was (as the same type could have different relations to different resources, e.g. parent vs child relations) and including the type meant the client could know what it was going to GET without actually g</pre> Ben Niven-Jenkins 2012-03-21T22:51:45 http://comments.gmane.org/gmane.comp.web.services.rest/15859 <pre>A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system. My use-cases/scenarios are: 1) Some resource in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}"). 2) The URL "{additional-properties}" returns a list of key/value properties for reading. 3) For each key/value in the list there will be links for a) editing the value of the key, and 2) deleting the key. 3a) Editing is as simple as PUTing a new value to the URL. 3b) Deleting a key is as simple as a HTTP DELETE of the URL. 4) The list also contains a link for adding new properties. What would be a suitable (simple) media-type for this? I am considering ATOM (which is nice for lists), but that seems like quite a bit of overkill. HTML might also be useful (but does not support PUT, but POST would be okay too). A home-grown application/vnd.ab</pre> Jorn Wildt 2012-03-21T14:24:34 http://comments.gmane.org/gmane.comp.web.services.rest/15858 <pre>We're coming up with a relatively common problem in our API where we define a media type then need to make different parts of it optional for GET (remove references that are not valid to allow HATEOAS) and POST (leave out parts of the media type that are filled in by the server when creating a new resource). Rather than defining all of the attributes as optional (which often makes most of the media type optional) and requiring clients and servers to check for the existence of many attributes, it seems better to instead define vnd.mycorp.myapp.Widget (used for GET and PUT) and vnd.mycorp.myapp.NewWidget (used for POST) as separate media types which make different parts of the representation optional. This seems like the most RESTful/HTTP friendly way to solve the problem, does anyone see any problems with it (other than it creating lots of similar media types)? Cheers, Jim </pre> Jim Purbrick 2012-03-21T14:00:01 http://comments.gmane.org/gmane.comp.web.services.rest/15856 <pre>Hi folks, might be wrong on this, that's why I ask it here. Today I took a look at HTML5 cache for offline browsing and prefetching resources: http://www.html5rocks.com/en/tutorials/appcache/beginner/ What's your opinion about that? Am I assuming correctly - if you use the manifest you drop support for the original HTTP cache spec[1]? "Once an application is offline it remains cached until one of the following happens: 1. The user clears their browser's data storage for your site. 2. The manifest file is modified. Note: updating a file listed in the manifest doesn't mean the browser will re-cache that resource. The manifest file itself must be alternated." Given this, I don't see the point of HTML5 cache. Please open my eyes :) [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html </pre> Alessandro Nadalin 2012-03-21T12:43:31 http://comments.gmane.org/gmane.comp.web.services.rest/15849 <pre>I'm currently embarking on a question to fully understand REST so i can move my company towards architectural independence :). Once we design the back end (service) we will be able to just any device we want to communicate with our systems (IPAD,IPhone,Android,WPF,ect...) I'm currently reading "REST In Practice" by Oreilly. I'm sure a lot in this group have read the book. I just finished chapter 5 "Hypermedia Services" which is arguably one of the most important and most difficult concepts to understand with REST. I found myself getting lost while reading the chapter but i kept reading hoping by the time i got to the end everything would make sense. Well everything doesn't. Some concepts are still really really fuzzy. I'm going to reread the chapter and post questions as i start to get confused (there probably will be quite a few). I know one of the first questions i had was on rel link. I understand the basic premise behind rel attributes(to provide a general documentation for how to interact with the lin</pre> nikonguy74 2012-03-19T17:40:47 http://comments.gmane.org/gmane.comp.web.services.rest/15817 <pre>I am working on a project that is attempting to implement a RESTful service layer (including HATEOAS) for a customer facing web application/portal (followed by other applications and integrations leveraging said service layer). We are looking for some professional consulting to review our approach and provide us some guidance on the architecture and implementation. I thought I might be worth reaching out to this group to see if anyone could point me in the right direction for qualified -expert- REST consulting. We are progressing fairly well in our implementation, but unfortunately we are by no means REST (implementation) experts, so we definitely could benefit from the advice of someone/someones who has "been there, and done that". </pre> developerbob 2012-03-08T17:19:12 http://comments.gmane.org/gmane.comp.web.services.rest/15792 <pre>HI all One topic that keeps coming up in my recent conversations is about the scope of REST and whether it applies both to client and server i.e. is the application the server, or is it the combination of client and server? Yes definitely REST is a client-server architectural style... Assume I have implemented my server in a RESTful way i.e. it adheres to all the constraints / is hypermedia driven. - If I have no clients actively consuming me can I say the application is RESTful? i.e. is the RESTfulness determined by the server. - Is each client + server combination considered an application? - If I have two clients, one which consumes my application using hypermedia and other that doesn't / hardcodes dependencies on my URIs then is the entire application non-RESTful? - Or, is it that really there are multiple applications (client1 + server, client2 + server) with one being RESTful the other not. - Are there actually three applications? one the server app, and</pre> Glenn Block 2012-03-07T18:10:38 http://comments.gmane.org/gmane.comp.web.services.rest/15785 <pre>hello. http://dret.net/netdret/publications#wil12a is where i have "published" the first draft of the "The 'profile' Link Relation Type, Internet Draft draft-wilde-profile-link-00". specifically, here are the links for the two available versions: - HTML: http://dret.net/netdret/docs/draft-wilde-profile-link-00.html - ASCII: http://dret.net/netdret/docs/draft-wilde-profile-link-00.txt this is not a properly published I-D (yet), because the I-D submission window closed yesterday. however, i will submit this -00 version as soon as submission opens again by the end of march, and any comments and changes to this -00 version will be incorporated in a new -01 version to be published in early april. thanks and cheers, dret. </pre> Erik Wilde 2012-03-06T18:36:11 http://comments.gmane.org/gmane.comp.web.services.rest/15768 <pre>hello RESTafarians. http://dret.typepad.com/dretblog/2012/03/resource-profiles.html is a brief blog post about my plan to write up a I-D proposing a "profile" link relation type for the IANA registry. any comments on that idea would be highly appreciated, and if there is more support than pushback, then i expect to publish a first version within a week or two. thanks a lot and cheers, dret. </pre> Erik Wilde 2012-03-05T20:24:09 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.services.rest