Re: How much REST should your Web API get?

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

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/