Turns out REST APIs weren't the answer (and that's OK!)
HTML-код
- Опубликовано: 9 июл 2024
- A decade ago, it seemed like everybody was talking about ReST APIs and HATEOAS, blog comment threads bristled with spirited debates about whether something was, or was not, a REST API, and we all thought hypermedia was the key to building long-lived APIs. And yet here we are, a decade later, building just as many APIs as before but seems like hardly anybody's talking about hypermedia... so what happened?
NOTE: At 8:14 or so, you can hear what sounds like a cat in this video. I am absolutely baffled as to where this came from, as there weren't any cats (or kids, or anything else that might have made a weird meowing squeaky noise) anywhere nearby when I was filming this. I've decided it must be a Ghost Cat: one of my cats who's no longer with us is now haunting my OBS installation. Let's see if they show up again in any future videos.
Links:
Roy Fielding's dissertation "Architectural Styles and the Design of Network-based Software Architectures":
ics.uci.edu/~fielding/pubs/di...
Roy Fielding: "REST APIs must be hypertext-driven", October 2008:
roy.gbiv.com/untangled/2008/r...
Hypermedia Formats:
SIREN: github.com/kevinswiber/siren
HYDRA: www.hydra-cg.com/
JSON-LD: json-ld.org/
Collection+JSON: amundsen.com/media-types/colle...
HAL - Hypertext Application Language: stateless.group/hal_specifica... 
Развлечения
I'll stop calling it "REST" when we stop calling whatever we're doing "Agile".
I am so glad I left mega corp when Agile came along and went to a small startup. Agile was the death of software development.
Bruh just because we're using JIRA doesn't make it Agile
@@KeithThompsonFAMU97 truths, its just Kanban, nuthing else o:
That mismatch is the reason why most people call it RESTful today.
I always call it RESTish or REST-like
@@andrewmazar4921 How about NAP (Network API Pattern). Not quite a full REST but reasonably close.
@@ulteriormotif I could use a nap alright
more of this please. More explanations re: the difference b/tw the standards, the intent of their designs, the hazards of using them, the hazards of not using them, the hazards of not using ANY of them, and more info on how folks just "roll their own" and why that's good & why that's bad.
My favorite part is that you ended the video reminding us to look after each other.
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 think at the very least it means using HTTP. The rest is negotiable.
“Hypermedia as the engine of application state.” HATEOAS.
I think it is still viable for certain cases, even if Dylan disagrees. I have not finished the video, yet.
To me if OpenAI can create client library for you and it’s useable then you’re a Rest API.
I think this is close to the right approach. Let the pedants endlessly discuss how many blahblahblahs can dance on the head of a pin. Meanwhile, I got stuff to do. This video was super annoying & I wish it said that in the title.
I think it is apt that HATEOAS begins with the word "hate" in uppercase, because that pretty much describes my feelings towards it :) I find that writing a frontend for a true HATEOAS API is a lot of unnecessary extra work with loads of additional requests, whereas I enjoy that when I write my own backend, I can build massive JSON structures that delivers exactly what my frontend needs.
And yes, that might introduce a slightly tighter coupling, but I prefer that APIs (be they network request or objects and methods) are designed to limit the workload of each other, rather than to achieve some lofty architectural ideal! But of course, that is an opinion :)
Well, those pushing the idea ignore the simple reality that real world apps end up with a ton of data they don’t need, and making a ton of calls to get the missing parts. And the idea that I can write a front end through the backend is at least next to stupid (more likely fully into MORONIC)
"my backend, my frontend" that's the point. You own both.
Consider an API made by a third party. Would you rather have an API where there is missing documentation, the documentation is outdated and incorrect, you have no idea what all endpoints are available or what they'll be named, and where the endpoints change regularly and break your application whenever they do or
a HATEOAS API where you literally just need the root URL and you can click through links from there just like a website to discover whatever else you need to and navigate the whole API just like a website and where the owners update the links regularly but your client doesn't break because it's using the rels not the links which aren't changing....
@@neildutoit5177 Yeah most of the third party APIs I use in the system I manage, are full REST APIs with links to everything etc. It is such a blessing, I don't need to anything to figure out how their pagination works, I just follow the provided link. :)
The "tuning in" part at the end was great. I'm rattling my brain on similar phases that are more symbolic than practical now. Could argue number dialling is one. Great video either way :)
I like "hang up", referring to ending a telephone call - that one goes all the way back to the days when telephone handsets were actually wall-mounted, so you literally hung the handset up... then "hang up" became synonymous with "put down" when telephones switched from being wall-mounted to being freestanding on your table/desk, and now it means "push the bit of your touchscreen that's currently showing the 'end call' button".
@@DylanBeattie not to mention that the universal icon for saving is still a good old floppy disk ;)
@@jayishappy "Save file" is a floppy disk, "open file" is a yellow cardboard folder, suggesting that somebody runs around at night printing out all the documents from the floppy disks and putting the printouts in the yellow cardboard folders.
Skeumorphism is *weird*.
@@DylanBeattie as it goes with radio buttons (from actual radio devices), menus (actual restaurant menus), icons (religious paintings), calculators (from calculi, small pebbles). Metaphors (from to move across) really are the engine of language and it's fascinating (I recommend "The Unfolding of Language", by Guy Deutscher, to anyone interested in human language evolution)! I think we only notice the original meaning in those words for which we aren't young enough.
Goodbye originally meant god be with ye
Love that your RUclips videos are as well researched and full of background as your talks, another awesome video Dylan
This, 100%
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.
I feel is all sbout selling cloud...
Need a more safe model to sell , model timeshare cant works.
Hence refactoring bybthe goodbold category theory with monads andvlogic topology...
Hence no acid crud butbbase crud😊
Many 'Restful' APIs have difficulty in the taxonomy of the url's i think. The problem i face that design often requires methods that are not easily identified by the resources/entities but by some function on them and thus a Url path with a verb instead of a noun makes more sense.
For example in the typical example of a API with classes, students, grades etc what do you do if you need a method that returns a grade average? Or the best student?
Also sometimes if you have extensive searching, filtering etc it just seems cleaner and simpler to have a simple URL and use a GET with body instead of the more correct RESTful taxonomy with URL and query parameters which becomes super long and harder to analyse in logging, dashboards etc.
RESTful apps are decidedly anti-CRUD. Thinking about REST as CRUD means you missed some important bits.
@@markvanderwerf8592for an average grade, you can "GET .../average" or "GET /metrics" or some such thing. Using this approach, everything properly scales and caches.
@@markvanderwerf8592 /api/v1/classes/:classId/grades/average
If you wanted to be ultra REST you could /api/v1/classes/:classId/grades?operation=average
I've always watched your NDC conferences but didn't realise you had your own YT channel until now! Keep up the awesome content 🤍
Case in point: `snmp` remains the least "S" protocol I've ever come across.
Like some of the other commenters here, I've never come across the hypermedia aspect of REST until this video, so thanks for educating me on that. As for whether I'd be adding it into some of the APIs I've built....probably not. For me the main benefit of REST is that it's a very standardized way of fetching and editing resources while also being fairly lightweight. A tool like swagger seems to make an actions section of the response entirely redundant, because realistically all that would ever be is just documentation for the developer consuming the API as they write their client, once it's actually running, the actions would almost certainly be ignored. I can see a potential benefit to having links for paginated results, but in the past I've just had my endpoint take page size & page number as optional parameters. Next and previous links could be a nice touch, but more of a minor convenience feature than anything that actually substantially changes how clients interact with the 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.
You need to parse the result and display the result dynamically using links, buttons etc. To be able to display the results in a user friendly format you need some sort of directives in the response to specify placement, colour etc. So basically you need to develop your own version of a browser, markup language and css type language. Hint: we already have these things, just use them. Arguing if something meets someones definition of a REST API is a waste of time
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.
Huh. Had no idea you had a youtube channel. Thanks for the information and inspiration over the years, my guy.
Brilliantly explained at great fast pace! Fantastic!
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.
But muh separation of concerns!!!
This was the way of web programming 20 years ago with "Web 2.0"... Funny that (probably young) people think that this is something new in 2024 and even a good choice. There's a reason why development left that muddy trail many years ago.
@@-Jakob- literally nobody in the htmx community thinks htmx invented sending HTML. Just because people used to do things a certain way and they don't anymore doesn't mean that way is objectively, irredeemably bad.
"There's a reason why development left that muddy trail many years ago." Yes, because HTML didn't have the tools needed for highly interactive interfaces, and when implementing them via JavaScript, it seemed more logical to imitate native app toolkits rather than build something that works with the Web model.
Yay s and cross site scripting
I consider it a good choice sometimes because backend technology has come a long way from back then. This makes this Web 2.0ish approach actually feasible for some apps (not all of course, but no technology is suited for all apps)
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.
There's nothing inherently wrong in modelling RPC's as an HTTP POST with JSON bodies in both request and response. The common REST frameworks can easily handle this, so why not use them if that's what the developers and users are familiar with?
Thumbs up for the callout against returning an error in a 200 OK.
I go for "resourcefulness" often. I think the decent idea there is turning verbs into nouns or in other words recording events as facts; aiding full fidelity of information without duplication.
Your API is a crying shame, you give REST a bad name!
Hall of shame, but yes. It falls apart, and we take the blame.
@@barneylaurance1865 You promised me JSON, then sent XML. 😞
Woh wu wu Woh wu
Woh wu wu Woh wu
Woh wu wu Woh wu
Woh wu wu Woh wu!
You promised me JSON and then sent XML
Great insights into the history of Rest and API design in general. Thank you Dylan
I've been using and creating APIs for well over a decade and somehow I never knew about the hypermedia stuff.
I was aware that it existed. I just never have time to investigate adding those links. If I have a an api endpoint for customer information /customer I will either have /customer/custid/invoices or /invoices/custid. Instead of parsing out the what can be done with the links, where all the heavy lifting has been done on the server side. The application code in browser implements the business logic, requests resources without hyperlinks and makes decisions about how to present the UI.
How though? Have you never once wanted to read the paper that invented the thing you're spending all your time on?
@@neildutoit5177 It is easy enough. Most of us start with just needing to get data from the backend to the font end and visa versa. If you can't do that all else is academic. Tutorials and libraries are focused on that. Everything related to hypermedia besides pagination is not needed. I need to get my app out the door. I know how I am coding my front end. Taking the time to duplicate my front end UI logic in hypermedia is counter productive to hitting deadlines. You can argue that is the case because the programmer does not understand Hypermedia. However, the reality is that 90%+ of REST API's are about shuttling data and not about using hypermedia properly.
It's easy up until the hypermedia part, then it's a big old grooooaaan
I always found those pushing hypermedia to be hyper full of themselves solving problems that don’t apply to a real world.
I don't know very much about REST and I've been trying to learn and this is the most helpful thing I've encountered so far.
From the OpenAPI specification: "The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs..." So there you go: "HTTP API". It might or might not be RESTful. Usually it is not. I usually call them just HTTP APIs or HTTP-JSON APIs when talking with developers who at least should know their stuff. And I might call them REST API when talking with people who use the word REST without knowing what REST actually means.
When I was getting started as a web developer I thought that REST APIs were slower than GraphQLs because they rested. I often wondered why someone would build something that was slow because it took rests.
Dylan, you didn't mention OData; have you used it? I spent a lot of effort working with it on a project and there is some VERY good but also some bad.
I love how your cat is screaming at you at 8:14
Other than that amazing video, is interesting to think about what sw companies call REST APIs to meaning basically what Swagger tries to do with OpenAPI
When I see the acronym HATEOAS, I often think "Aw, they've simply mis-spelled Halitosis."
HATEOAS
"The OpenAPI Specification (OAS)"
yep, that's how I feel
Lol !!!!!
The alternative to rest was soap. Once you add HATEOAS, the simplicity advantage of rest evaporates but you still have the lack of tooling.
Isn't it simpler? I'm finding it simpler to implement.
Inserting the HTML into the page is incredibly simple, reconstructing JSON into HTML is the complex bit
This is superb Dylan! I shall share it at will next time someone says: "It's not really ReST". Oh yes, and very chuffed to have been a small part of the motivation for you to click "publish" on this ;)
As someone who started off with SOAP APIs I definitely loved the "if something calls itself simple it probably isn't" reference. Great video!
soap and disco sucked !
'RUST is safe' moment
I once saw a YT comment calling REST a "RPC with extra steps" and this stuck to my head... it really is just RPC with extra steps
If you completely misuse it, yes it is.
Considering basically every network request could be classified as a RPC, this isnt very enlightening.
No
@@user-oj7uc8tw9r you dont have to get so pedantic, most (all?) frameworks map endpoints directly to a user provided *function* , literally RPC, but with the parameters mangled between the HTTP verb, URL, body... and God forbid, headers
This is a common refrain in the gRPC community.
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.
thanks, i got some new vocabulary to weaponize at work. good stuff
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.
Well put - so many people don’t see this.
Thanks for this! Really interesting and succinct history. My company is in the process of rolling out some new internal dev standards. It's fascinating to me how rarely people understand the original intent of certain patterns and technologies. We use a kind of hacky RPC design that people still call REST 😬🤷🏽♂️
Great content! I 'm still doing SOAP as it is a kind of industry standard over here in germany for insurance data. Beside that I try to explain my customers, that rest needs hypermedia in a format like HAL (most used by me) and HATEOAS. Most of the teams I 'm working with don 't even know HAL or HATEOAS in these days. Ofcourse hypermedia is an additional expense on REST APIs. But the benefit out of that is worth it.
Thank you Willie Netstat
Well said my good man! Salutaitons from Romania!
What was the Question?
My apologies for having anything to do with SOAP
Do you think there's an argument for redefining rest to mean Richardson Maturity Model Level Two (the level just before Hypermedia), as described by Martin Fowler on his website in 2010. That may be closer to the common usage. And then we can talk about HATEOS APIs for level three, which is what Fielding calls Rest.
I absolutely think there's a case for adopting a term to describe RMM level 2 APIs that doesn't have hypermedia controls as a prerequisite. Whether that term is REST or OpenAPI - or something else? - is kinda the question that inspired the video. To me, everything up to RMM level 2 has always been about applying design patterns based on HTTP itself - and most folks who do that end up with similar and broadly interoperable implementations, some of which include links, which I think works pretty well. The point where I think it usually falls apart is hypermedia *actions* - once you go beyond GET into PUT/POST, things get a lot more complicated.
@@DylanBeattie Right. And without going back to look at the dissertation again I'm trying to work out how it even can make sense to say it's not rest if it doesn't have hypermedia. We don't say a web page is not a web page just because it doesn't have links.
Maybe it's just that links join what would otherwise be multiple APIs together - so what would be one rest API with hypermedia technically becomes a collection of many separate rest APIs if you delete all the links.
In principle full HATEOS rest should enable APIs including links to resources that are part of APIs provided by totality separate organisations, but I don't remember ever seeing that.
@@barneylaurance1865 If it isn't in 6nf it's not a real database!
Regardless of Roy Fielding's intent, I think this is what REST and HATEOS have come to mean. I wouldn't use OpenAPI as a synonym for RMM2 as the terms address completely different things. OpenAPI isn't a type of API, but instead a standard for specifying an API. The exact same API could be specified using different standard, like JAX-RS.
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.
You're not alone :) BTW, another thing I don't like about REST APIs that they tend to push business logic to the frontend. And the languages we use on the frontend (practically, JS) are usually not really a solid choice to implement business logic...
You're not wrong, but there is a vast universe of use cases that can be satisfied with simple objects and CRUD operations and it's wise to start with a lightweight framework if there isn't an obvious reason not to.
@@fang_xianfu I know, I just don't find it a good fit for most of the stuff I tend to work on. I'm currently doing storage and backup automation/reporting. Simple CRUD does not satisfy our needs, yet we still went with "REST" because:
* that's what everyone uses
* it's simple with django-rest-framework or flask-restx
* it integrates well with Swagger (OpenAPI)
Which I think are all poor reasons to use a CRUD framework for an RPC coding style.
Thanks a lot!
I have been trying to understand REST since I first started using it with Ruby on Rails back in 2010.
this channel is a rare gem
Interesting content 🎉
Rest in Peace
The hypermedia part of the concept is effectively an optional subtype of a generic API concept.
In practice, this ISN'T used as an API (Application Program Interface - a way for one application to request services of another), but as an integral part of a single application - a website containing web pages, with possible links to other websites.
The GET, POST, PUT, etc. HTTP methods are used for API calls, but those calls don't generally return hypermedia, they send or return formatted information.
So, in modern parlance, 99% of all official REST "APIs" are just webpage calls.
And of the APIs that use HTTP protocol, 99% do not qualify under the original definition of REST.
But they use the exact same calling and return protocol.
One advantage of the HTTP protocol as a wrapper for APIs is that it is easier to test such an API, and you can have an entire standard web protocol stack supporting it.
One disadvantage is that it requires a relatively heavy stack, and is innately tied to TCP, meaning that you lose the other protocols in TCP/IP.
You could call these APIs SHAPE (Stateless HTTP API Protocol Environment), or any other acronym, but nost programmers call them REST, as they are identical except for the return values. And the API type is not determined by the input and output but by calling method (where REST with hypermedia shares the same method as data queries).
Would the inventor really classify an API that returns a webpage based on whether the returned webpage has hyperlinks?
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)
And for me, I use post to create resources (my reasoning is that if the result is not identical after two requests than it is not a put), I use put to set all the data in an resource (this way even if someone somewhere changes something the result of calling out again is the same), patch for updating specific values in a resource (the ones I passed in the request), get for get, query parameters for query, etc
Because of my constraints, I very rarely use put, I use post a lot for creating resources and lots of patches and gets
For documentation, that's what OpenAPI 3.0 is for.
I agree with you 100% regarding the terminology. Unfortunately, the PHBs of the world love their buzzwords, and if the proposal does not include those buzzwords, it does not get accepted. Thus, one is forced to refer to RESTful APIs, when you bloody well know that they are not going to be since there will be no hypermedia references, they are at best just plain HTTP/S APIs, and swagger does a brilliant job expressing the methods and parameter models.
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.
Server Sent Events. Browser listeners.
@@joshuaholmes5325 good point. Another reason to not use HTTP. Bidirectional comms.
@@joshuaholmes5325 good point. another reason REST is rubbish... broadcasting and bi-directional comms. But also, we have Web sockets and gRPC. Have to get around to using those.
JSON Apis that try to have links and stuff are just the worst lol.
Yeah I haven’t seen this be fully successful either. Sounds neat but it’s You Are Not Gonna need it.
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.
To me (and I know this is in conflict with Roy Fielding's definition) the defining part of REST is that the requests contain the state of the application (so servers don't need to maintain any per-client state between requests), which enables caching and horizontal scalability. I don't really care about the rest of it.
See, that's the frustrating thing... I don't think your definition *is* in conflict with Roy Fielding's definition; it just doesn't go far enough to satisfy a purist definition of REST. In his dissertation, Roy's derivation of REST explicitly has a stateless constraint (5.1.3). The six prerequisite constraints for REST - client/server, stateless, cachable, uniform interfaces, layering, and code-on-demand - actually form a pretty good set of constraints for building any kind of HTTP API, and I think a lot of folks over the years have, consciously or unconsciously, conformed to those constraints, created a system they consider to be RESTful, and then get a bit of a shock when the purists take them to task over it for not having hypermedia controls.
"I don't really care about the rest of it" is a great presumably accidental pun.
@@DylanBeattie Perhaps it is the purists who are making an error - specifically conflating REST and HATEOS. If REST required hypermedia controls, there would be little if any difference between REST and HATEOS, rendering the terms redundant. In contrast, omitting hypermedia controls from the definition of REST makes the terms significantly different from one another.
I'm looking forward to the day where we interop via timelines more like git (which is a meta api with time as its domain) than by rest/rpc/graphql. This way, instead of an api server, we would have the analog of a public "repo" space (only it's for more than just src and contains multiple repos like GH) and consumers could clone/fork the data locally for an offline-first, occasionally connected scenario. Then if the use case demands it, they could push changes back upstream. So basically git, but where the git config itself and all metadata (issues, discussions, wikis, etc) can live *inside* the protocol graph itself. This allows on-graph, content addressable metadata for schemas as well, so you get swagger-like metadata but itself versioned alongside the data and other metadata.
With finer granularity than git provides, we could skip the klunky repo/file/package level mechanics and fork smaller src constructs like the data models themselves. And since the protocol acts like the general case vs gits special case, we can content address and reference each piece of this puzzle, including decentralized identity. Ah, a decetralized, distributed interop with time and space as the first class citizens for a completely new experience, just in time for ubiquitous ai models that will need new collaboration paradigms to interact with humans and with each other.
Yes that's the day I'm looking forward to... soon. Soon!
I'm in the 3rd camp. I see REST as a naming convention for APIs. HttpVerb describes the action, URI Route describes the noun the action is applied to. This is in contrast to many controller-oriented schemes where your route may be "GetThing" and you send it as a form Post or whatever, or graphql where this information is all encoded in the request payload. It's not a catch-all umbrella term at all, but also HATEOAS is not part of my mental model of it at all.
I don't think I've ever seen a REST API that returns anything else than JSON data. Sometimes there have been links in the data, but that is very rare.
The term was probably corrupted almost immediately. Also returning hypermedia from 3rd party API rarely is the thing you want, usually you want the raw data.
And SOAP was simple, compared to CORBA which it replaced.
Working with graphql I realised how REST good actually
Spot on how ppl misuse the term REST API.
btw, I think Hypermedia doesn't make any sense at all. It might have well intention but has no real usage in reality.
Agree
Can you give an example where it does not make sense?
@@CristianVasquez the whole thing from beginning to end
@@chauchau0825 your argument is certainly strange
8:15 meow spotted
Any rules that REST had has long been forgotten, we live in chaos land now where all responses now return 418 and we go make some tea
The rules never made sense
That’s quite pedantic. Roy may whine, but he built his castle on top of Internet foundations.
8:15 I think your cat doesn't like Swagger
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.
Ehich is why im always sure to call it restless
OMG I hate that GQL returns 200 for errors. Makes finding those errors in the console so very much harder.
ROCKstar API
Great info, well presented. More of this. Subscribed.
Those who don't learn REST are doomed to reimplement it... poorly.
Your cat clearly has strong feelings on this topic.
pat the kitty 8:14
That was an amazing video. Sub'd, like'd, and now commenting for the algo.
Also, SNMP. Four lies in one acronym. :D
You mean the simple network management protocol that isn't a protocol, isn't simple, and doesn't manage networks? Yeah. Love that one.
How could you leave htmx out of this video?
While I've read most of Carson Gross's essays and articles about REST, hypermedia, HATEOAS, etc, I haven't done much with htmx beyond "hello world".
On the timescale we're talking about, though, I don't think htmx has been around long enough to have had a significant impact on the way we build, and talk about building, APIs. REST dates back to 2000, SwaggerUI first shipped in 2010, and htmx 1.0 was the end of 2020. If it sticks around (and I think it might!), I'll make another video in 2034 talking about how htmx revolutionised API design. Promise.
@@DylanBeattie For a lot of webdevs of our generation, Gross is THE RESTafarian lol
I haven't used htmx in a project like ever, but it's influence is already so large if I ever know of concepts like HATEOAS etc it's because of it
Surprised that HTMX wasn’t mentioned
Why? It adds nothing to this
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.
i like the term REST-like
REST is great. Like most Version 1.0 of, well, anything, there will be things that are due to be changed. Hypermedia may have ended up being useless but the idea of using the HTTP protocol and standards as opposed to the SOAP junk was great.
What we have now is an even simpler, more cleaned up REST that transmits less data. Add on OpenAI and we even have documentation.
I've been a professional software engineer for over a decade and have worked at several companies, and in my expedience so-called "RESTful" services is the software version of "We're Agile, but..."
It seems to have evolved into a genetic umbrella term that conveys the general idea but doesn't necessarily conform to a consistent standard.
Hypermedia is not incompatible with graphql, just attach the necessary affordances to the responses
Ok , i guess i was working with openApi. Works fine for CRUD. So i will just keep going on.
web turned successful: "citation needed" LOL ;)
I am a simple man: I see Dylan Beattie, I hit play.
Learned more in the first two minutes of this video than 99% of the programming content/tutorials. Thank you sir. Subscribed.
SMTP might be the exception that tests the rule.
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.
I bloody loved this. Will be tuning in to all your shit from now on 🥰
we can borrow a pattern used in games that define similarities by appending a '-like' to it. roguelike, soulslike. variations are roguelite or mixing like metroidvania (metroid, castlevania). why not call it RESTlike and acknowledging its impurity by this inocent appended word. you could span a spektrum by calling the other side of the Spektrum maybe RPClike or whatevertf graphql is supposed to be. i have seen conflicting opinions online regarding openapi/swagger that would be resolved by not calling it neither REST nor RPC in nature but something inbetween.
1:52 DCMA incoming from NK
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.
Rest FHIR api is great because is a government standard and set of models that you can use. And then the medical APIs ignore it and do whatever they want because is fairly incomplete
One of my favorite APIS I consume returns XML or strings depending on how it failed. Always 200 and empty messages some times. If the response looks like json it likely succeeded
SOAP - was an oxymoron. Simple .... 'nuff said.
I often wonder how that protocol was invented, every developer I every met hated it the first time they saw it. Although, from memory, it was organisations like IBM that promoted that protocol.
I love this type of content
I love the way and depth of which you explain things
Background noise: cat in heat or small child? 😂
You know, I have absolutely no idea. No cats or children on the premises. I didn't even notice that until somebody pointed it out on the recording...
Sorry but i don't see the link between openapi and rest/hypermedia ? Openapi is just a way to describe your api. Would like to see examples of what you meant please.
Thanks Dylan, that was the video we needed!
Whatever was the intention of the REST pattern. In reality today it is HTML requests. While Hypermedia sounds good in a doctor thesis, it is rather complex to implement and does not reflect the requirements of the real world where cost matters most. Thats why people adopted quickly but dropped the hypermedia and represential state and there you have it: The OpenAPI "standard".
We should've stuck with SOAP, but who am I to say?
There’s enterprise
And the rest