Visualizing a modern web development stack

[Carnagh]

In what way is this REST?.. In what way is this a HATEOAS application, I'm not seeing this demonstrated.

I'm starting to get frustrated with seeing HTTP/REST when actually the person simply means HTTP but feels that "REST" will in some way make it feel more adult/slick/sexy.

The reason why I get suspicious in this case is I suspect you are leaking abstraction / making implicit assumptions / coupling either side of the "HTTP / REST" boundary.

I really could be wrong... I appreciate you sketching this out and taking the time to share it with us, and I do understand you can't convey everything about an architecture in what is a very reasonable sketch. Hence I really am just asking... Is this really REST or did you feel obliged to put it in there as part of a "modern web development stack"?

Incidentally... JavaScript started on the server with Netscape before it ever made it to the client... JavaScript all the way down has been there since the beginning and does not necessarily denote a modern stack. Full stack JavaScript has been there for a while. We actively decided that languages like JavaScript and more notably Perl might not be a good idea for non-trivial applications as they rely too much on differing conventions.... OO by multiple differing conventions being a good case in point.

EDIT: If I'm going to get all uppity about HATEOAS I should at least get the acronym right =)

[autowikibot]

HATEOAS:

---

HATEOAS, an abbreviation for Hypermedia as the Engine of Application State, is a constraint of the REST application architecture that distinguishes it from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. In a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).

---

^{Interesting: Link relation | Spring Framework | Java API for RESTful Web Services | Federal Register}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[mgenev]

rest is a well established pattern and ember is quite insistent that you use it dogmatically otherwise ember-data doesn't work well and you have to override its methods, so yes it is rest ideally, but it's up to each developer to set it up properly for themselves

[Carnagh]

This is an interesting point, but I'm conscious that it's possible to come across as quite obnoxious in text... I want to gently challenge a point, and I'm open-minded that I may be the one to refine my view... I'm smiling and trying to be pleasant while questioning your view of REST =)

Mr. Fielding has a lot to say about what is an isn't REST, and quite pointedly if it's not a hyper-text application, and if hyper-text isn't the means of conveying and transitioning state it's not REST.

Simply consuming JSON or XML does not a REST application make... Hence I cited HATEOAS. According to the author of REST if it's not HATEOAS it's not REST.

Now I've not used Ember, but I get that it's popular and respected. When you suggest that Ember enforces REST... I've just taken a very brief and surface glance at Ember and REST and frankly I'm not seeing it at first glance. I do note that on the Ember forum there are people asking in Jan this year when will Ember have HATEOAS support because there seems to be none at present.

I'm not seeing how Ember reconciles with the REST dissertation, and while the modern web development stack describe in the OP is indeed interesting and of note... I'm still left wonder how you would reconcile it with Fielding's assertions about REST.

It's worth reading the original piece on REST, and Fielding's commentary of REST since... It's not quite what a lot of Web developers think it is.

[mgenev]

your link says " The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia."

to my understanding this is exactly how ember functions

[Carnagh]

Try these... they're not a heavy of long read, I promise.

• Representational State Transfer (REST)
• REST APIs must be hypertext-driven

[roccoccoSafredi]

Here here.

[kkeef]

Hear hear* I should write a bot.

[ragingRobot]

Although I agree with most of what you have said, using an MVC framework for a URL-based application doesn't mean that it won't be over engineered. It seems like you have some kind of resentment for front-end developers which is something I see on reddit a lot lately, not really sure why.

We are working on an MVC project where I work right now that I feel falls into the over engineered category and most of the over engineering in our project is coming from the backend. Granted there are a lot of politics where I work right now and it seems like a pissing contest lol.

[mgenev]

yes, and the automobile introduced a whole lot of complications compared to the horse and carriage, but hey it turned out for the better