Smarter Single Page Application with a REST API 

I enjoy every video you make. Thank you for awesome content, sir!

I really like that explanation and the distinction between Runtime and Design Time. Thanks for another great video!

In a recent project we started with an approach like this initially but the problem is is this sort of thing has inherent complexity, and in our case we started off using some tooling that ended up not being flexible enough to do certain things and without auto generation or good tooling for these types of links doing this sort of thing manually I think would be a maintenance nightmare. We ended up just not using these sorts of links. I find with something like this you may end up having a lot of the same communications with client developers and the reduced communication overhead provided by the the smart links may not be worth the complexity of the implementation. Also from my experience with front end development I feel like it would be awkward to navigate these link trees and I would much prefer just having direct endpoints that I know upfront to get what I need. It's worth posing the question that if specs or practices were originally designed a certain way, yet for years people never used them "correctly" and over time people actively moved away from those patterns it was possibly (likely even) for good reason. I find truth is more in how people actually use things than how things are intended to be used. It's kind of like how a dictionary isn't the source of truth for meaning in language, language evolves and adapts over time and meaning is contextual based on the people using it. Specs will only be hard in contexts where they are enforced programmatically or simply don't work if not implemented strictly and outside of that they will be interpreted and evolve like language does. That said with GraphQL being popular in React and Node.js ecosystems, smart self documenting apis like this seem to popping up in popularity, but GraphQL last I checked was mostly tooling bottlenecked for non Node.js backends (and I feel like running into an issue where you can't easily do something you need to do with existing tooling and be forced to implement a complicated spec yourself or switch pattern mid way is a landmine that doesn't seem like it's worth inviting). So there is definitely merit in having a flexible spec to allow consumers to move rapidly without having to communicate (as much) for new endpoints, I just don't like the overhead and would doubt it is worth it in most cases. I do however love just simple autogenerated open api docs that most frameworks seem to have now, almost no work to add and instant value.

Definitely used to adding e.g. "CanDo, IsType, CanAddObject, HasStatus" etc. type of fields to my responses in order to achieve this, but the links idea is very cool. Potentially much less code for me across projects, though I dwell deep within a forest of entity services. My cave-mates may like this idea as it sounds like it could simplify a lot. There is (hopefully) nothing invalid my services would allow them to do in handling a request so I find skepticism of the actions list unconvincing given that one is only fetching a single root as clarified already by other comments. This also sounds like it simplifies thinking about the client as a performer of tasks, as it is always bringing one's focus back to the current action set.

great content! thank you for making these

I'm addicted to your channel!

Runtime and Design Time :)

Thanks for this great explanation, On my project I use Clean architecture, and I was trying to implement HATEOAS, but I couldn't find a way to do it properly, Since it requires both the presentation layer (because it's related to how we present data) and the application layer (since we need to know what the user can and cannot do). Is there any clean way to do it. Thanks in advance!

What about versioning in this scenario..? what if some clients needs to use v2 of "unavailable"..? If we change the backend service to use v2 then wouldn't it impact others..? Or do we need to maintain client specific uri's ..?

On a REST api resources are requested and retrieved. This approach seems to append extra information that is not part of the resource: the actions. This is really a form of metadata but it's mushed into the resource representation. What if you request a collection of items and each item has a different set of actions?

Hi. Any thoughts on GraphQL (instead of REST) for api with SPA? Just looking at that as an option for VueJS and Net Core

This is great! What about in cases of user roles? Example admin can modify all properties of an entity, but a lesser role can only modify a few set properties. Would returning the allowed properties the user can modify be the best approach here?

spotify uses this technique too

Wow!

That is clever I like it it :)

Pretty cool explanation! That's exactly because I don't like using redux on Angular. Any ideas on good architecture of the server code to work following this pattern? I tried to code HATEOAS and it become into spaghetti code

Sounds very interesting, but I can already feel that it will be a little bit too complex to implement, with relatively little reward. I will look into this in detail during my spare time and see if the first impression I got is true. :) Thanks for your videos.

Is there a reason you use POST for the sales endpoints? Wouldn't PATCH be a good choice here since you are doing a partial update? Good video!

Hi. I'm subscribed for a while to your channel. I'm based in Ukraine, so I guess that's the reason that I don't have "JOIN" button. Is there any other option to become dev-level member?