Loading ...
Sorry, an error occurred while loading the content.
Advanced Search
Author
Subject
Message
Special notice only

30 results from messages in rest-discuss

Advanced Search
  • ...LinkedDataFragments/Client/blob/85b67be35/lib/LinkedDataFragmentsClient.js#L33 Have a look at the high-level algorithm here: http://ruben.verborgh.org/blog/2014/03/11/towards-web-scale-web-querying/#querying-with-linked-data-fragments Detailed algorithm: http://linkeddatafragments...
    Ruben Verborgh Mar 11, 2014
  • ...impossible to link to a machine-accessible version of a resource. I've written a high-level blog post about these problems: http://ruben.verborgh.org/blog/2013/11/29/the-lie-of-the-api/ If somebody doubts whether a REST API is a good idea, this could be a great starting point...
    Ruben Verborgh Nov 29, 2013
  • ...Notification: Feb 4, 2014 Camera-ready: Feb 12, 2014 Workshop: Apr 7, 2014 at WWW2014 in Seoul, Korea WS-REST2014 is organized by: - Ruben Verborgh, Ghent University – iMinds, Belgium - Thomas Steiner, Google Germany GmbH, Germany - Carlos Pedrinaci, The Open University, UK...
    Ruben Verborgh Nov 19, 2013
  • Fetching Sponsored Content...
  • Hi Mike, > Then you don't need to call it a "description document" since it's > just another resource with links that is part of your application. Of course, this would just be another linked resource (maybe even rel=describedby). But the peculiarity of this resource would be that it enables clients to understand how to act upon another document with a generic media type, thereby...
    Ruben Verborgh Oct 18, 2012
  • Hi Jan, Thanks for the very detailed answer, that clears up a lot of the questions I had concerning coupling. > If you do not do that (write specific media types) but instead use generic ones (application/xml, application/json) you absolutely, 100%, need some out of band coupling somewhere if you want your client to do more than 'parse as xml' or 'parse as json'. And you will...
    Ruben Verborgh Oct 18, 2012
  • Hi Dean, > You could implement a Maze using HTML: all the client would need to know is how to follow hyperlinks to navigate the maze like https://en.wikipedia.org/wiki/Colossal_Cave_Adventure. While maybe true for a maze (although, how would the client know what end state it should reach?) this is not the case for other applications such as shopping, reserving, commenting, annotating… Best, Ruben
    Ruben Verborgh Oct 18, 2012
  • Hi all, It’s an often-discussed topic that continues to puzzle me: self-descriptiveness is encouraged to reduce coupling, but how specific can we describe without introducing coupling? And specifically: to what extent could “self-describing” formats such as RDF help out here? Let me borrow the Maze+XML example used in a previous discussion [1]. So the problem is: a server...
    Ruben Verborgh Oct 18, 2012
  • > but that doesn't mean that all resources in every API should be > bookmarkable, it depends on the API and what you are trying to > achieve. Non-bookmarkability is fine for resources that don’t exist anymore. I don’t expect the server to keep everything. For resources that still exist… no reason to change the URI every now and then. It’s part of a good resource design. Ruben
    Ruben Verborgh Sep 28, 2012
  • > It invalidates the term 'entry point' entirely. If you are allowed to > bookmark any resource (posts, comments, etc) then any resource is an > entry point, at which point stating that your blog index is an entry > point is meaningless. But what’s the point then of giving those non-entry resources a URI? I’d argue that the definition of “entry point” depends on the client...
    Ruben Verborgh Sep 28, 2012
  • > If every URI in your app was supposed to be bookmarkable > then the term 'entry point' would be meaningless. Not really. I’d like to bookmark posts or comment from a blog, but that doesn’t invalidate the blog’s index page as an entry point. By the way… why would anybody be against stable URIs? Is there a good reason not to do that? Ruben
    Ruben Verborgh Sep 28, 2012