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 the "If" or "Overwrite" conditional headers defined in this specification. If the server evaluates a conditional header, and if that condition fails to hold, then this error code must be returned. On the other hand, if the client did not include a conditional header in the request, then the server must not use this status code. [2] </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 future'-pattern: A user can frame a resource by posting a frame to it, create or update child resources by posting these to the frame instead of the resource and have these changes take affect somewhere in the future: We use Frames, Catches and Patches as a means to let clients transfer preliminary state as if it were final state, with the guarantee that this state can be finalized later. The terminolgy should be understood as follows: A Frame represents a snapshot view on your resource, a Catch refreshes your snapshot and a Patch effectuates your changes to it. Frames present resources as if your are the only one changing them, without actually putting your changes to effect. So you don't bother others with your changes and others don't bother you with theirs... Yet. Because you can choose to catch up with patches others made by posting a Catch. And if you would choose to post a Patch, others may in turn post a Catch to catch up with your changes. From within a Frame you see exactly the same resources as from outside a Frame, at least for the time you don't do any (preliminary) updates from within that Frame and as long as nobody else effectuates any updates. When you do update resources from within your Frame, these resources only reflect your changes within that Frame; from outside your Frame these resources will show as before. One could say a Frame provides you with a view on your resources as if your changes have actually taken place and as if changes someone else made after you created your Frame have never taken place. Only when you post a Catch to your Frame, it will reflect changes that were finalized from outside your Frame and only when you post a Patch to your Frame, your changes will in turn be effectuated. After posting a Patch, all resources will reflect your changes, both from within your Frame and from outside your Frame; only other Frames that were created beofre you patched won't show your changes as long as these don't catch up. From this point on you can keep on using your Frame to make new changes. These changes will be treated like before you posted your first Patch; you will need to post another Patch to finalize these new changes. A Frame provides certainty when it comes to finalizing your changes, but only to a certain extend. A Frame comes with a time-out; when the Frame expires it won't accept any postings anymore, which means you will loose your changes after your last Patch. After each Patch, a Frame's expiration date will be reset. As long as a Frame does not expire, it will use a pessimistic claiming strategy to ensure you can finalize your changes later. As a consequence, updates you make from within a Frame, may bounce as resources may already be claimed by other users from within their Frames. All can be illustrated using the following scenario with two users that add an element to the same diagram of a model in parallel: // before posting a frame User 1 sees a single element in diagram 1 of model 1 // after posting a new element within his frame, the diagram shows elements 1 and 2 User 1 GET &lt; at &gt; /models/1/diagrams/1/elements -&gt; [element 1] User 1 POST frame &lt; at &gt; /models/1/frames -&gt; frame 1 User 1 POST element &lt; at &gt; /models/1/frames/1/diagrams/1/elements -&gt; element 2 User 1 GET &lt; at &gt; /models/1/frames/1/diagrams/1/elements -&gt; [element 1, element 2] // as the updates of User 1 are preliminary, User 2 also sees only one element // after posting a new element within his frame, the diagram shows elements 1 and 3 User 2 GET &lt; at &gt; /models/1/diagrams/1/elements -&gt; [element 1] User 2 POST frame &lt; at &gt; /models/1/frames -&gt; frame 2 User 2 POST element &lt; at &gt; /models/1/frames/2/diagrams/1/elements -&gt; element 3 User 2 GET &lt; at &gt; /models/1/frames/2/diagrams/1/elements -&gt; [element 1, element 3] User 2 POST patch &lt; at &gt; /models/1/frames/2/patches -&gt; patch 1 User 2 DELETE &lt; at &gt; /models/1/frames/2 // even though User 2 posted a patch, User 1 still only sees elements 1 and 2 // however, after posting a catch, frame 1 does reflect the changes of User 2 User 1 GET &lt; at &gt; /models/1/frames/1/diagrams/1/elements -&gt; [element 1, element 2] User 1 POST catch &lt; at &gt; /models/1/frames/1/catches -&gt; catch 1 User 1 GET &lt; at &gt; /models/1/frames/1/diagrams/1/elements -&gt; [element 1, element 2, element 3] User 1 POST patch &lt; at &gt; /models/1/frames/1/patches -&gt; patch 1 User 1 DELETE &lt; at &gt; /models/1/frames/1 // now that both users shared their updates by posting a patch to their frame // the actual resource reflects all the updates and show the same to all users User 1 GET &lt; at &gt; /models/1/diagrams/1/elements -&gt; [element 1, element 2, element 3] User 2 GET &lt; at &gt; /models/1/diagrams/1/elements -&gt; [element 1, element 2, element 3] I'm curious what other's think about this approach, so please share your thoughts on this pattern. Regards, Diederik van Leeuwen </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 requirements on Atom Processors." Does this mean that the documentation of any given rel can NOT say anything about how a link should be used? On the other hand, RFC 5988 (which updates 4287) says&lt;http://tools.ietf.org/html/rfc5988#section-4.1&gt;: "Relation types [...] can specify the behaviours and properties of the target resource (e.g., allowable HTTP methods, request and response media types that must be supported)." </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 or know, and let me know what level of support (based on the model) do you think that framework offers. It will be great including all platforms, from PHP tp Java, .NET, Ruby and any other scripting language around. Now, please bear in mind this is not a competition, where higher level means that framework wins. As stated in the article, even level 1 fully supports REST, only the developer may need to do some extra work to get there. What we are looking for is evaluating the frameworks in a way that helps the framework makers and the users to identify the needs and solutions. It is like suggesting a tool and testing it in the field for tuning. Thanks to all and I'll appreciate any comment, be that here or in the article at DeveloperFusion. Thanks a lot! William Martinez. Article Link: http://www.developerfusion.com/article/141194/evaluating-rest-frameworks-part-1-a-maturity-model/ </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.com/JornWildt/Ramone, under the Open Source MIT license. Thanks for all the help I have gotten from this list - now its time to give something back :-) Hopefully </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 clients communicate with and use content negotiation to either return text/html (for browser) or application/vnd.whatever+json (for programmatic clients). With this approach only the code that converts resource objects to representations have to differ. I have a couple of concerns with this approach as well: 1. There are features that should be available via api only, meaning html representations may not have the same links available in json for the specific resource. I'm not sure this is correct as depending on which media type the client asks it may get completely different features. Feels kinda wrong, but is it? 2. Earlier or later the two media types will start to diverge, specifically when we have to take care about evolvability of the 'machine' media type, while that is not a concern for 'humans' html. And here we go again having to have different links between html and json representations. 3. Browsers do only GET and POST. But that can be pretty easily overridden by X-HTTP-Method-Override to do PUT and DELETE. What are your overall thoughts and experience on the topic? Thanks, Vitaly </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;yahoogroups.com &lt;*&gt; Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ </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 getting it - e.g. "I don't need to know about barTypes right now so I won't bother getting them until I need to know about them" But afterwards I thought to myself while my arguments above seem reasonable there must be other good reasons (that I can't immediately think of) for being explicit with types &amp; relations in links in RESTful APIs. Can you help me with your thoughts on what those other good reasons are? Thanks Ben </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.abc+xml is also a possibility. What would you guys do? Thanks, Jørn </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 link provider). The question is what would you see if you go to the rel link? Is it something a person is suppose to interact with (say to get documentation for new links added to a specific response) or something code can interact with to determine what it needs to do? Unfortunately in the book they don't give an example of what a "rel" page would look like. For example the link: &lt;link rel="http://relations.restbucks.com/payment" href:="http://restbucks.com/payment/1234" /&gt; If you typed in "http://relations.restbucks.com/payment" into your web browser what would you see? thanks... </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 the other two composites of client and server? Interested in your thoughts and this is not a leading question :-) Thanks Glenn </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