Re: How much REST should your Web API get?

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
>
>
>
>