Відео

I see now how Word Perfect died. Everything Novell buys goes up in flames. I used to use Linux SuSE unitl Novell bought it, and compeletly destroyed it.

Martin Fowler should be put where he belongs, that is in the place of someone making money be telling and not doing. And in his statement on definition of REST - well he needs to spend more time in language arts where we learn that definitions change over time.

At work, we've got a 3rd party API that goes one stage further than returning an error message with a 200 code.... it returns NO error message and a 200 code.... even when your request has failed... neat huh?

i actually implemented the HAL RFC draft for one of our backend APIs to enable HATEOAS. being able to reference related resources in the response, but also giving clients the ability to request the embedding of these resources on the fly turned out to be really useful. but so far i think no client implementation really uses the links to discover actions.

I didn't know about stiglers law but i've claimed for years that the person who invented murphies law didn't get credit because something went wrong!

JSON Apis that try to have links and stuff are just the worst lol.

But graphql and grpc can still be rest, they are just middleware to enhance basic http communication. However, they don't really go against the rest principles.

Yeah the issue has always been there's no point to the hypermedia part for most APIs. Nice idea, but impractical, difficult, and pointless. So REST in the IT business world just naturally became about having something better than SOAP to create, update, and read data remotely. I think it's fine to call these kind of APIs REST, or RESTful. Everyone does.

In most cases the hypermedia is useless, because something will be programmed based on the spec rather than reverse engineering from submitted responses. Links could perhaps be applied if the API is designed to be called by a presentation layer, but that's the only case I can think of where it might have a use.

All very Gödelian ;-) You can't prove Rest within a Rest framework. It's like pure maths arguing with applied maths.

Awesome video. My personal opinion... REST is the dumbest possible solution to the problem of "client code wants to run server code". I feel like we've stepped backwards. Give me RPC with autogenerated client-side proxy stubs so I never have to give a dam about the network implementation. The real solution is not to use HTTP for this kind of IPC. I want a dedicated protocol that web servers can utilise alongside HTTP.

HAHAHA, we're still using SOAP

8:15 I think your cat doesn't like Swagger

I remember when HATEOS, and hypermedia driven API's in general, were the darlings of framework developers and architecture astronauts; however, even during their heyday it was obvious to me that these ideas wouldn't survive contact with reality - they added a lot complexity (and thus development time and expense) while having little practical benefit for most applications.

REST will be around in 15 years .... just like Javascript, we are stuck with it. I don't mind it. I like the ask receive nature of it.

Now if you were to send the "Login" button itself instead of a json saying there should be a button - you get HTMX. It exposes the ability to request HTML elements themselves and layouts them in, which can then request more, different elements. The most web native hypertext solution possible, no protocol negotiation beyond "do you speak HTML". You just get sent the finished button.

This advice is superb 👌

How my watching went : "what is this guy even talking about, whole world is sitting on top of rest apis..." .... "Oh he's gonna talk about ACTUAL REST" 😂😂😂😅

This is a masterpiece

8:14 great video, now show your cat please 😸

I’m one of the few stubborn assholes that still insists on hosting my own email server. However, I do so on a Linode VPS because my home internet hasn’t been the most reliable. Couldn’t send any emails for 3 days last week because of Spamhaus. No explanation given, no evidence I could find of my server having been compromised, nothing. Pain in the ass.

Background noise: cat in heat or small child? 😂

Returning an application error in a 200 response is a valid choice. Why overload the transfer protocol signaling when you can and should handle the application error gracefully, and let the application domain remain loosely coupled.

I’m curious if you intentionally didn’t mention HTMX. Doing HATEOAS with HTML makes a lot more sense to me than doing it with JSON because we don’t need to synchronize client state and server state, considering JavaScript isn’t doing a bunch of element creation. HTMX is great because it extends HTML as a hypermedia beyond just the anchor and form tags. It’s a very simple yet powerful idea.

Ok , i guess i was working with openApi. Works fine for CRUD. So i will just keep going on.

I used to weasel my way out of it by using the term "a REST like API'

web turned successful: "citation needed" LOL ;)

REST for me was always about CRUD and defining the data taxonomy in the URL path. Sometimes you added extra data, sometimes that extra data was trivial to compose so didn't need to be sent. You did whatever made the API as clean and stateless as possible because that is what matters for scaling the backend.

this channel is a rare gem

I've been screaming about this for years. You can pass the majority of parameters on the fricking URL. Or use http post. REST APIs just add more wrapping to the data which needs to be unwrapped. My simple PHP web application was 175 times faster by not having to wrap and unwrap data with JSON. You're just adding more overhead.

Very interesting and well explained summary.

imo hypermedia in APIs is just bloat. If the API is well documented then the links are worthless and the consuming code probably doesn't care. The only thing they do is slow down the response time.

REST lost its meaning for me long ago. Tons of pedants running around trying to define it in different ways has left me thinking: “it’s just an API”

I never figured out how to actually consume a REST API. I get links back, but usually these links are formulated in a way where coercing it into a shape that is suitable to be fed back into the HTTP client is a lot more work than just putting the paths in the code instead.

Aww man, give it a rest will ya 😂

The alternative to rest was soap. Once you add HATEOAS, the simplicity advantage of rest evaporates but you still have the lack of tooling.

My apologies for having anything to do with SOAP

i build APIs with only GET method without building POST endpoints, and use query params to represent the params passed in, and its simple and works well. just like how unpure function calls can return different results, HTTP GET idempotency doesnt really need to be adhered to

It is interesting to hear the history of the term. I think it has become basically synonymous with anything that uses HTTP verbs, and very often Json payloads. I didn't realize the original definition specifically included hypermedia. Interesting though to see the rise of htmx in the last year or so. I don't think it's for me, but it definitely swings back towards the use of hypermedia directly across the network.

I'll be the weirdo here, but personally, I never really liked REST APIs. They're good for simple objects and CRUD operations only, but any time you try to represent something that doesn't fall within that realm, you're producing kludgy nonsense. Personally I'm more of a fan of RPC over REST.

Genuine question : "Hyper" - why? Why Hypermedia, Hypertext, Hyperthirdthing - why was "Hyper" used in the context of the internet?

From a consumer of a lot of web APIs, REST is by far the easiest - the tooling is there, it's easy to understand (syntax, documentation) and all languages support JSON (or Xml). I cannot really think of a suitable alternative - there is GraphQL, but this is an absolute mess, which is difficult to understand, has a syntax which is not JSON compatible, and has limited language support. I can understand some of the complaints of REST (e.g. over-fetching), but where this is a concern, it can also be remedied easily.

I've been using and creating APIs for well over a decade and somehow I never knew about the hypermedia stuff.

My teammate told me returning null with 200 OK is restful

The JSON APIs at my work are definitely not REST. Not only is there no hypermedia, almost all of them are actually RPC rather than representing resources, because we don't build CRUD APIs. We also don't use e.g. jsonrpc. I'm pushing to just switch to gRPC but people like to use what they are familiar with.

That was an amazing video. Sub'd, like'd, and now commenting for the algo. Also, SNMP. Four lies in one acronym. :D

Imagine wearing a shirt from a megacorporate code forge that wants to make software into social media website & that requires an account to make upstream contributions to projects or even use search on code.

What a lovely take. as far as REST-adjacent patterns: I don't think I've ever written a single API that faithfully adheres to what RESTful actually is... For example, I constantly break the POST/PUT pattern - for me PUT is create a resource, PATCH is edit a resource, and POST is "perform some specific action against a resource", and that's *definitely* not RESTful, but it comes up a lot... And that's fine - I think what matters is Consistency and Documentation. (it helps also that every API that I've ever written has been self-documenting through a REPORT method to the same url as a kind of side-channel)

That mismatch is the reason why most people call it RESTful today.

Just callt them webapp and webui and implement the clients needs already! Enough with the mental instant gratification...