- Ok. I was away and lost all the fun, got late to the party, and so... But cannot resist putting my two cents in this. 1. I share most of Antonio s feelings inMessage 1 of 139 , Sep 1, 2010View SourceOk.
I was away and lost all the fun, got late to the party, and so...
But cannot resist putting my two cents in this.
1. I share most of Antonio's feelings in his rant. Sometimes I do not agree on his appreciations, but the points he made are valid. Actually, there are point I see on other threads as well.
2. REST, as I understand, is a style. You can build it with whatever you want. We need to apply the "practicality" principle (do things in a practical way) and avoid the Golden Hammer Syndrome.
3. To me, Standardization is more related to common understanding, of all participants in a networked application. The registering part is a way of doing it. There me be better or worse ways, all accomplishing the same goal.
4. REST is free to be used privately, or so I feel it. Only a few guys and me. There is nothing I can find that forces me to use the WEB in general and to take into account all and each of the nodes that are connected to it.
5. Not all is written, yet. It is not true the current "standards", official or ad hoc, are the only ones that will ever be, no new kids allowed.
6. If I use the web, doesn't mean I'm entering the big and only one networked application, that I should agree with all the existing nodes in the web the way I send my messages (and the ones that will be in the future too!). And here (as with everything else) I can be wrong: I see the web more as a framework, a supporting implementation for trillions of networked, individual apps. There I can use others services, create my own, be a global provider or simply build a small page for my family to see mi baby's pictures. I see no practical use to have a full body of standards watching over me and punishing if I post the pictures using my own, non-patent, 4D format. I see practical use in having that body registering the common, most used, most practical, proven and approved format we can use, so if I'm new in town, I can go there and pick the best for my app, if that one exists. And the best means the one that will support many of my quality properties needs, which MAY be: interoperability, readiness, compactness, legibility, security, etc.
7. Example? We work on a testing system that builds thousands of nodes, for a few minutes, to load test servers. That is a network of testing nodes, on the cloud, talking between them with proprietary, efficient formats. Once all that info is gathered, it is served in standard formats to clients. That is practical. RESTful? May be, but who cares? It is working and working fine.
--- In email@example.com, mike amundsen <mamund@...> wrote:
> Not sure if this is exactly where you are heading, but here my POV:
> REST style is protocol-agnostic (not limited to HTTP)
> REST style is not limited to Web or Internet usage (e. g. has
> application for communication between autonomous devices in a closed
> custom network)
> REST style using HTTP over the Web is not limited to using the common
> Browser for the "client" (e. g. desktop applications. console apps,
> bots, etc.)
> Finally, the REST style is not the only interesting style for building
> distributed network applications.
> Join me at #RESTFest 2010 Sep 17 & 18
> ---------- Forwarded message ----------
> From: António Mota <amsmota@...>
> Date: 2010/8/12
> Subject: Re: [rest-discuss] Atom feed vs. list of orders
> To: "Eric J. Bowman" <eric@...>
> Cc: Jan Algermissen <algermissen1971@...>, Peter Williams
> <pezra@...>, Rest List <firstname.lastname@example.org>
> I think there is a fundamental question that should clarified
> unequivocally by the experts on this list - I do have a opinion but
> I'm not a expert so it's just that, a opinion.
> Is REST realm - the problem-space where it should be applied, or where
> it makes sense to apply it - exclusively the Web? Or it should, or it
> can, be applied to the more general space of network-based software
> architectures, thus including intranets (network based apps that runs
> exclusively inside a company) and extranets (the use of private
> networks and/or the public infrastructure of the internet to connect a
> limited number of companies - considering limited does not equal
> Because if it is indeed only applicable to the Web - and please note
> that Web != Internet - to making websites that are going to be used by
> humans using a browser, most of the discussions here don't really make
> sense. Otherwise, some people assumptions when they deal with the
> issues presented on this list are, to say the least, limited. Or plain
> wrong, not to say the least. Now I do understand that one or the other
> approach may have to do with each one background, people who's work is
> limited to the web may have a different point of view than others who
> worked over several areas and platforms along the years.
> For instance, what is the sense in saying "Media type identifers
> inform clients what codec or engine to use for deciphering the
> payload" if my clients are *not* browsers? And also please someone
> correct if I'm wrong by saying "ubiquitous" != "standard"...
> While it is true that intermediaries don't look inside the msg to
> perform their function, why is that true also for servers that are not
> web-servers? If I have a application/mystuff+xml, all the
> intermediaries understand what they need to understand - they read
> this as application/xml. Why should the server be limited to this,
> knowing that I, as a architect/designer, although I *do not* have
> control on intermediaries I *do* have control over the server? The
> coupling using application/xml or application/mystuff+xml is, from
> this point of view, exactly the same. And I do see advantage of using
> "application/mystuff+xml" on content-negociation *on the server side*,
> because like that I can even put that content-negociation on my
> *server-side connector* - which I also control, thus relieving the
> server from workload, improving balancing, implementing scalability
> and effectively implementing layered design - but of course all this
> is just impelementation.
> Also, and all please excuse my rant but these things must be said...
> why some people on this list insist in treating people sometimes like
> morons and sometimes like little kids in the classroom in front of the
> master? Shouldn't we all consider the others as pairs, even if the
> knowledge of some are superior to the one of others? Aren't we all
> professionals? What's the "you kids"? I'm trying not to say harsh
> words, but do I have to publicize that I develop software for the past
> 30 years, 27 of then as a professional, 20 of then as a independent
> consultant / contractor? That I started to do web sites since the
> earlier 90's and I kept working on the web (although not exclusively)
> until as recently as 2007, when I designed and implemented a web-site
> login method using telephony - where you had to call a number to be
> authorized to enter the site and you will be logged in until you hang
> up the call. Should I also say that I did a web site to a chicken
> delivery service - I didn't put that on my CV since I made it to a
> friend and it was not a paid job - or actually it was, I got paid in
> chickens... I even designed myself many animated gif's... How's that
> for publicity? I don't know, maybe it's just me that dislike being
> treated with this kind of disdain?
> Nevertheless, I really think that this list should clarify the
> question I talked above, because frankly if REST is only about the
> web, I am plain wrong in my approach and it is better for me to
> understand that now and move on to other technologies. And I think
> others will benefit from that clarification also.
> On 12 August 2010 07:19, Eric J. Bowman <eric@...> wrote:
> > Media type identifers inform clients what codec or engine to use for
> > deciphering the payload. Nothing more. Clients are limited by how
> > recent their codec/engine is for the given type, or how fully they
> > implement that type. Media type identifiers are _not_ meant to say
> > anything about the nature of the payload. Doing so would introduce
> > coupling, violating the layered-system constraint, and result in more
> > media types than anyone could possibly keep up with, defeating the
> > whole purpose of self-descriptive messaging.
> Yahoo! Groups Links
- +1 and that s just this thread :-) I would love for Roy to be that person since the topic always leads back to his direction. GlennMessage 139 of 139 , Oct 3, 2010View Source+1 and that's just this thread :-)I would love for Roy to be that person since the topic always leads back to his direction.GlennOn Tue, Sep 7, 2010 at 10:23 AM, Bob Haugen <bob.haugen@...> wrote:
Yahoo says there are 103 messages in this thread. The discussion is
circular and will never end.
May I suggest starting a new thread with an appropriate title to focus
exclusively on the IANA registry issue, where each person who has a
different position states their position clearly and succinctly, and
thereafter we refer back to that thread as a FAQ?
Best I think if somebody with moderator-type skills summarizes all of
the contradictory positions at the end of the thread, so we don't get
into a who-get-the-last-word fight.
I could start one, but I don't really have a position other than
wanting to shortcut permathreads.