This was meant for the rest-discuss group, not the RESTEasy group.
On Thu, Jun 25, 2009 at 10:47 PM, Solomon Duskis <sduskis@...> wrote:
> (Looping in the REST of the crowd)
> What I'm trying to get at, is that in order to add relevant links, you need
> to do some analysis on which links might be relevant. That requires an
> analysis of how your API will be used by different types of users. It's not
> about too many options, it's making sure that the "reasonable possibilities"
> exist based on the different needs of the likely users of your system.
> There are tried and true methods that Website "information architects" use
> in order to envision how the human users of the website will likely want to
> interact with the system.
> REST developers don't have those "tried and true methods" yet. Sure, there
> are distinct differences between REST APIs and websites. However, websites
> are the most RESTful systems that we're aware of.
> I suggested "information architecture" because while it does have plenty of
> aesthetic related concerns, it also deals with "the structural design of
> shared information environments" and "practice focused on bringing
> principles of design and architecture to the digital landscape" (
> http://en.wikipedia.org/wiki/Information_architecture). Those seem to fit
> the needs of REST APIs.
> You can build a better API (Application Programming Interface) if you
> better understood how the programmers want to use it. You're API will likely
> suffer if you don't take those kind of aspects into consideration.
> Even though I've thought about approaching RESTful design from this
> perspective for quite a while, I still have very few practical "best
> practices" from other REST APIs to fall back on. I'm sure you can even
> think of additional "possible links" in Kenai... For example, what would a
> user want to do after "Requests to VNet Resources?"
> http://kenai.com/projects/suncloudapis/pages/CloudAPIVNetRequests - I
> assume that there are things that can be done next...
> Re: pretty URLs. No, that wasn't my point. However, while the client
> applications shouldn't necessarily care about interpreting the meaning of
> the URL, the programmer of that application might care...
> On Thu, Jun 25, 2009 at 9:40 PM, Craig McClanahan <craigmcc@...:
>> On Thu, Jun 25, 2009 at 6:24 PM, Solomon Duskis <sduskis@...:
>> > ergo: REST APIs should be designed similar to the way Websites are...
>> > perhaps "Information Architecture")
>> Hmm ... I don't think I agree with this very much. In a human facing
>> website, aesthetics are generally much more important than in a web service,
>> which will lead to decisions about WHAT information is shown as well as HOW
>> (in this context, this is mostly about what links you might offer to go
>> other places). In a web service, there is no such concern, and you should
>> focus more on providing all possible links that might be relevant ... the
>> client machine will not complain about having too many options :-). And the
>> client developer will likely thank you for offering all the reasonable
>> If you are talking about "pretty URLs" when you are talking about design,
>> I *definitely* disagree with you. Clients of properly designed web services
>> (i.e. those that care about the HATEOAS constraint) will not try to
>> interpret the "meaning" of a URL ... they will just follow it if it does
>> what they need. People, on the other hand, tend to care about the URL that
>> shows in the location bar of your browser.
>> Craig McClanahan