Re: How much REST should your Web API get?

Great, I've added some of those references to the wiki:
https://github.com/restlet/web-api-style/wiki/References

Would you be interested to contribute directly to the GitHub project?

Best regards,
Jerome



2013/5/2 mike amundsen <[email protected]>

> just jumping in here:
>
> - CoAP[1] is a UDP-based protocol for small devices (sensors, etc.) that
> has support for hypermedia [2].
>
> Modifiability
> As for handling "co-ordination" for releases/changes between client and
> server, IME, this boils down to a desire for the system to support
> safe modifiabilty.
>
> - Erlang solved this problem using language constructs and a supervisor
> model.
> - Years ago (too long...) I worked on Intra-net implementations that
> relied on shipping sandboxed code for client-side execution. We called it
> "scriptable clients" and this was all before "browser" was a thing<g>.
> - Gmail is one big pile of portable code that auto-installs as needed and
> carries all the new funftionality
> - I've worked in systems where the entire system was a ball of
> configuration settings. new features were released via configuration only.
> bear to manage each config, but quite reliable.
>
> the above all all examples of "co-ordination" of release/updates w/o a
> dependence on hypermedia.
>
> If you focus on the properties you need instead of the techniques you use,
> you find there are many, many ways to reach your goal.
>
> [1] http://tools.ietf.org/html/draft-ietf-core-coap-16
> [2] http://tools.ietf.org/html/rfc6690
>
> Oh yeah, the Taylor link... http://www.ics.uci.edu/~taylor/
>
>
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://www.linkedin.com/in/mikeamundsen
>
>
> On Thu, May 2, 2013 at 2:34 PM, Jan Algermissen <
> [email protected]> wrote:
>
>>
>> On 02.05.2013, at 19:48, Jérôme Louvel <[email protected]> wrote:
>>
>> >
>> > Jan,
>> >
>> > I remain a strong proponent of the idea that it is more fruitful to aim
>> at rethinking the problem to fit a sound paradigm rather than to blame the
>> paradigm for not fitting the problem (one's perceived view of it, that is).
>> >
>> > But when the paradigm isn't intended to solve a given problem, do you
>> think we should force the problem to fit into the paradigm?
>>
>> No, certainly not. What I am arguing against is what I experience so
>> often: That people claim some paradigm is a bad fit for a problem instead
>> of thinking thoroughly through the problem until they can make an educated
>> choice.
>>
>> >
>> > REST was never designed to solve all software architecture problems.
>> That's quite the opposite and what makes it so powerful to scale the web of
>> hypermedia documents.
>>
>> What does that mean: "and what makes it so powerful to scale the web of
>> hypermedia documents"?
>>
>> >
>> > Two concrete points:
>> >
>> > I don't buy the efficiency argument regarding discovery and granularity
>> of messages - unless you ignore caching and the possibility to tailor
>> representations for specific devices.
>> >
>> > You could also add HTTP compression to the mix. I'm a fan of HTTP
>> caching and content negotiation as well. The "Web API" style proposed fully
>> leverages those features.
>>
>> It just not as simple as taking half of REST and getting half the
>> benefits. REST works as a whole, not in 'layers' or 'levels'.
>>
>> >
>> > You write about the 'Web API style' "requires coordination between
>> clients and servers when changes are deployed" - doh... this eliminates
>> *the* (**the**) primary benefit to apply REST.
>> >
>> > Exactly, but if you ship a native mobile app or a connected hardware
>> device with no hypermedia capability at all (think about a dumb sensor),
>>
>> Now, there is quite a difference between a sensor and a mobile app. Who
>> says a mobile app cannot have hypermedia capabilities? And who would make a
>> sensor a REST client? I'd rather have the sensor send measurement data via,
>> e.g. UDP.
>>
>> > you definitely need to coordinate the clients and servers even though
>> you are fully and properly using HTTP.
>>
>> Hmm, can you be more specific about what you mean here?
>>
>> > This is why the vast majority of so-called web APIs are versionned and
>> based on stable URIs and representations structures. They can't always
>> afford to dynamically discover the user interface.
>>
>> I'd say, the vast majority of Web APIs fails to be RESTful because people
>> simply did not follow the style. Show me a single example that has been
>> deliberately designed  unRESTful on the basis of design principles. To me
>> this is just the same old discussion over and over again: People make a
>> (rather unedcuated) claim, mistake that for truth and come up with
>> suboptimal design.
>>
>> And that is not only true for wanna be REST services, unfortunately it is
>> an all too common way to approach all sorts of IT problems.
>>
>> In my experience, people learn best if we do not settle for 'premature
>> agreement' but use, for example, a style to foster more flexible thinking.
>> Usually, whoever endures that process is thankful in the end.
>>
>> >
>> > You could say that native apps aren't needed and could be re-developped
>> as HTML 5 apps, but this isn't always possible or desirable.
>>
>> Either way, a native app makes a perfectly RESTful client if you design
>> it that way. Personally, I'd go a very long way to maintain the benefit of
>> not having to coordinate client deployment with API changes....
>>
>>
>> >
>> > Aside from systems that focus on sending fine grained control messages
>> around in (near) realtime, I have yet to see a case where REST does not
>> shine due to performance, scalability and the ability to decentralize
>> management of the deployment and release cycles.
>> >
>> > Again, my point is to take the best of what REST brings but not try to
>> apply it in cases where a rich hypermedia client is available,
>>
>> What is a "rich hypermedia client"? Can you be more specific about the
>> situation that seems to be the root cause for the perceived need that you
>> have to change the style?
>>
>> > but isn't so uncommon. I'm just trying to do REST justice otherwise
>> we'll get a backslash when people finally realize that the vast majority of
>> REST endpoints/APIs/etc. can't be used in a dynamic way like HTML is used
>> by web browsers.
>>
>> Can you explain what you mean by "a dynamic way like HTML is used by web
>> browsers"?
>>
>>
>> To me it remains unclear what the problem is you are trying to solve.
>> Please explain, I'm all ears.
>>
>>
>> Jan
>>
>>
>>
>>
>> >
>> > Best regards,
>> > Jerome
>> >
>> >
>> >
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>