Patent madness as usual RT @samj: Amazon's S3 patent: Distributed storage system with web services client interface appft1.uspto.gov/netacgi/nph…
1
2
@markusvoelter I would go with Rails for completeness, Spark for simplicity, Sitebricks for Guice and Spring MVC for, well, Spring users
1
@alpengeist_de But for all practical reasons, you only gain something with JRuby over Groovy, you don't lose anything relevant
@ewolff I wonder: What's your choice these days? Hopefully not JSF?
2
@darrel_miller "Opening your data to generic usage is costly." True.
1
@alpengeist_de Disagree; feel Groovy is oversold b/c of perceived but not real interop advantages, vastly outweighed by Ruby community size
1
2
@darrel_miller What performance are you referring to? developer, runtime, client, server? @landlessness
1
@alpengeist_de I second @myfear's JRuby recommendation -- such a vast ecosystem to draw from
1
@landlessness But of course this level of generality and server independence may not be in the provider's short-term commercial interest
1
@landlessness The ideal API will create a dependency to a set of interaction rules, independent of a particular (set of) servers
1
@landlessness Agreed that HATEOAS requires an appropriate client. Way too many servers are built in a way that creates dependencies on URIs
@landlessness Unless I misinterpret you, you conclude HATEOAS is not worth the trouble for APIs. I disagree.
1
. @sallamar I have a feeling I only ever see either too much or not enough hypermedia in APIs. And that includes the ones I design myself
1
Interesting video & slides from @landlessness, even though I strongly disagree with the conclusion blog.apigee.com/detail/hateo…
4
1
2