|
The HATEOAS part is usually missing from every explanation. It means like a webpage, you only need the starting endpoint url and from there you browse the API like a regular webpage. So you GET an endpoint, it tells you what it can do and what methods it accepts. So you GET the endpoint, it tells you: I can store a Foo for you at /endpoint/foo url. Something like POST /endpoint/foo. So you POST a Foo on /endpoint/foo and it will return something like 201 created and some additional info like the Id of the FOO that has just been created. So it could give you an option to GET the status of the Foo on url /endpoint/foo/thenewlycreatedfooid. In effect it makes the program traverse the API like a user does a webpage. etc. etc.
|
#
?
Nov 9, 2018 13:53
|
|
|
|
| # ? May 19, 2024 07:13 |
|
|
Just don't be that person spewing about HATEOAS or Richardson maturity model without a deep fundamental understanding of the domain and how it impacts your team/work. Many developers might not ever get to a point where those design distinctions matter at a significant level, and that's OK. Focus on really understanding:tef posted:rest: wow, we can build rich interfaces over a simpler rpc-like protocol, by using HTML, URLS, and a browser! and get pedantic about the rest later.
|
|
#
?
Nov 9, 2018 14:04
|
|
|
Love it
|
|
#
?
Nov 9, 2018 14:16
|
|
|
Mr Shiny Pants posted:The HATEOAS part is usually missing from every explanation. like hateoas is nice but outside of pagination it rarely applies to most apis realistically if you want to imagine what a restful api looks like imagine automatically generating an admin website then imagine adding tags to the html so it's easier to screen scrape and you might end up with a client library that knows _nothing_ about your service code:rest is about making a browser work at scale if you aren't _using_ a browser to access it, rest is pretty pointless
|
|
#
?
Nov 9, 2018 14:37
|
|
|
Worrying about what REST really means is mostly pointless nowadays because no one uses it to mean that. Everyone has a nebulous impression of what it means that mostly overlaps what everyone elses nebulous impression of it means. Problems arise where 1) the impressions don't overlap, and 2) you're really writing an API that needs all the features of a real RESTful interface. Problem one would be solved if everyone really understood what it meant, but that ship has sailed and the second one doesn't matter enough for most people writing an API.
|
|
#
?
Nov 9, 2018 16:13
|
|
|
I don't understand how a "sufficiently smart client" would ever be possible to "browse APIs" and magically figure out how to navigate through them. I can barely find the correct page for what I want to do for my bank's website, and I like to think I have a brain and a pretty good command of the English language. According to tef, Googling for which unlabeled icon button to press in Xcode to figure out how to boot the graphics debugger is very REST.
|
|
#
?
Nov 9, 2018 17:53
|
|
|
Suspicious Dish posted:I don't understand how a "sufficiently smart client" would ever be possible to "browse APIs" and magically figure out how to navigate through them. I can barely find the correct page for what I want to do for my bank's website, and I like to think I have a brain and a pretty good command of the English language. i mean, like i could explain it to you but I'm pretty certain I already have and you weren't paying attention the last two times—even so, i'm glad your ignorance has given you the confidence to argue things are impossible i mentioned plan9's use of passing filenames is effectively hateoas, but sure enough maybe I didn't explain the other ideas. so, let's take an example of automating an api client in a browser like fashion, like screenscraping with a screen scraping library: sure enough you have to write some client code to consume the website, but you can reuse the library for a variety of different services or websites. the point is that by hard coding the names of links, rather than the urls themselves, you allow you api to link to other parts, or grow or shard—changing the state passed around in the url—without updating the client. the notion of browsing here, isn't "magically figure out how to navigate through them", but, explicitly navigating through them, rather than magically figure out the right url to construct—it works the same way as going to a web page with a form and submitting the form, as opposed to knowing the url structure of the website and crafting urls in the address bar by hand and when i brought it up in the posts before, I asked you to imagine maybe marking up the html with machine readable structures, rather than presentational ones—having generic collection types, or ways to list an object with the methods available. the key idea is moving from application specific types to more generic representations—in html this means using forms or links, but you can use hypermedia to build descriptions of models, collections, etc a restful client doesn't have to look like a browser, in fact—a restful client might resemble some rpc library code:alternatively you could imagine that call 1—connects to the url, reads the admin data and constructs an object with methods/attributes to match call 2—api.Albums is one of the forms on the page, but it's a special form for model like collections call 3—a.add_to_playlist() works in a same way, the collection of Albums returned is like a webpage, a table with one form per row, with back and next links that the underlying library runs for you anyway, if you aren't too confused by "screen scraping", i have literally written an rpc library that works like this https://github.com/imbal/catbus
|
|
#
?
Nov 9, 2018 22:07
|
|
|
Thermopyle posted:Worrying about what REST really means If the people who've read the goddam thesis could wave their hands so we can tell who's recycling hacker news posts
|
|
#
?
Nov 9, 2018 22:08
|
|
|
The readme is terrible here, but essentially you drop a few decorators around your existing objects, and you're done! the client library asks the server to describe the api, and then constructs the right objects to use you can literally import the library in a repl, and play around directly without installing a schema or a stub meanwhile, here's another restful thing, which doesn't use http! https://github.com/tef/textfree86 the idea is that if you run a program inside a container, sometimes you want to run it as a normal program, passing it in files from your command line—this is a hack-upon-a-hack, but the client side cli tool is generic, and even handles tab completion! the 'restful' bit is that the protocol between client and server is simple, but over the protocol rich messages describe the interface—what command line args are accepted & their types
|
|
#
?
Nov 9, 2018 22:17
|
|
|
tef posted:anyway, if you aren't too confused by "screen scraping", i have literally written an rpc library that works like this isn't this just what soap is supposed to do like, in practice you don't do it at runtime but rather point visual studio at the wsdl file (and if you try to use something other than visual studio everything explodes) and let it generate ten thousand lines of code full of bizarre bugs, but it looks kinda like the same idea to me?
|
|
#
?
Nov 9, 2018 22:33
|
|
|
imagine a cat stretching over the atlantic, and then stop imagining the cat > isn't this just what soap is supposed to do yes, except it works and you don't need to second guess if you have the right wsdl, as there is no wsdl
|
|
#
?
Nov 9, 2018 22:53
|
|
|
I was paying attention the last two times, but my reservations still apply. You talk about all these hand-wavy things like "oh man what if it could just *find* all the albums because we put some machine-readable data there", but you never explain what this machine-readable data is, or what the standard for it is. You talk about this as if it's some grand idea separate and everybody using JSON-LD "just doesn't get REST".tef posted:with a screen scraping library: sure enough you have to write some client code to consume the website, but you can reuse the library for a variety of different services or websites. the point is that by hard coding the names of links, rather than the urls themselves, you allow you api to link to other parts, or grow or shard—changing the state passed around in the url—without updating the client. Instead of hardcoding "/albums" in our program, we now hardcode "@albums" and expect that as some data somewhere in our response, which we then now fetch. I'm glad we figured out which problem this solves: it solves the problem of the server writer changing the URLs around maybe sometimes. You know, that thing which you shouldn't do because it breaks bookmarking. Or *other* applications linking to you. Or sending users to cdn1.buttzone.fart instead of api.buttzone.fart because I guess putting a Squid proxy in front of everything is too hard and we demand a complete architectural shift to all clients to handle it. I am *not* defending typical RESTful in response to this, I just literally do not understand why the envelope format, whether it be JSON-over-HTTP or linked-RDP-triplets-over-HTML, is worth focusing on. tef posted:and when i brought it up in the posts before, I asked you to imagine maybe marking up the html with machine readable structures, rather than presentational ones—having generic collection types, or ways to list an object with the methods available. the key idea is moving from application specific types to more generic representations—in html this means using forms or links, but you can use hypermedia to build descriptions of models, collections, etc Let's ignore the HTTP and distributed systems part, just for now. Let's talk about a new programming model that uses this stuff, entirely locally. We're saying that defining strictly typed classes, functions with documentation, modules, etc. this is all too hard and too rigid. So instead, let's build a meta-type-system that has generic representations for machine readable structures, with objects that can list the methods available. What will such a program do with this model? Would code look drastically different? I don't believe it would. tef posted:a restful client doesn't have to look like a browser, in fact—a restful client might resemble some rpc library OK, so instead of you downloading the schema file, the server sends its schema over at connection time and the client adapts. This was literally the point of SOAP, and one of the parts that they threw out basically as soon as they realized how useless it was. So instead of having your API endpoints return a JSON blob, they return an HTML file with a JSON blob in a script tag somewhere which we scrape out. Got it.
|
|
#
?
Nov 9, 2018 22:58
|
|
|
tef posted:If the people who've read the goddam thesis could wave their hands so we can tell who's recycling hacker news posts /me waves hands Also, I don't understand your point in this particular post.
|
|
#
?
Nov 9, 2018 23:15
|
|
|
tef posted:imagine a cat stretching over the atlantic, and then stop imagining the cat It's a pretty neat idea to serialize RPC method signatures together with the data, sure. Very browser-like, as you say. What's ended up happening in the browser world though is that there is One True Client that people actually support (Chrome). Similarly, in the SOAP world, Microsoft shops use SOAP because it works if you use Visual Studio, while for everyone else it's easier to just generate the XML by hand than to try to use the autogeneration tools. I think there's probably some kind of reason for that happening.
|
|
#
?
Nov 9, 2018 23:18
|
|
|
Suspicious Dish posted:I was paying attention the last two times, but my reservations still apply. Ah that thing you said was impossible! Actually it is very impossible and you understand it! quote:You talk about all these hand-wavy things I'm literally summing up a thesis none of you have bothered to read, deal with it. quote:Instead of hardcoding "/albums" in our program, we now hardcode "@albums" and expect that as some data somewhere in our response, which we then now fetch. I'm glad we figured out which problem this solves: it solves the problem of the server writer changing the URLs around maybe sometimes. Yep! For example, it means that instead of a format having hardcoded urls against a service, we can return _different_ urls and everything still works—the point being that things across services work in the same way at the client Another example is that, many URLs won't be bookmarked—ephemeral or returned from the results of other calls. You can do wonderful things like passing in extra state, without changing the client. quote:we demand a complete architectural shift to all clients to handle it. Ah yes, my post that said why you said you should do this rather than explaining the fundamental principles behind rest—Oh wait! I was explaining what rest was. The thing you said was impossible then explained how it could work and elaborated some of the tradeoffs! Me: REST is literally what constraints the browser puts upon HTTP You: I'm Pickle Rick Again, In practice the closest people come to a restful client is screen scraping. quote:OK, so instead of you downloading the schema file, the server sends its schema over at connection time and the client adapts. This was literally the point of SOAP, and one of the parts that they threw out basically as soon as they realized how useless it was. Then they implement an admin interface in HTML which does exactly that. Also that's not what happened with soap, but whatever. quote:I just literally do not understand why the envelope format, whether it be JSON-over-HTTP or linked-RDP-triplets-over-HTML, is worth focusing on. Just wanted to pull these two quotes together where you berate me for giving detail and then ask for the same detail
|
|
#
?
Nov 9, 2018 23:35
|
|
|
"Why would anyone do this" "To make a web browser" "What's the point?" "Well, you know a web browser, right? That" "But what about APIs" "The ideas can be applied to the point where one api client can be used across _different_ services, without preconfiguration of every service possible" "Can you sum it up? I need to get back to my Naruto Marathon" "So using links instead of URLS (instead of ids)... well, this would mean that a twitter API could be reimplemeted elsewhere and the clients reused. With a more general API, you could have one client that can speak to all of your internal services, allowing introspection, debugging, as well as playing nicely with http middleware" "What you're saying is that analysing REST within the context of a single service is missing the point" "The whole point is making a browser that can work across different services. "
|
|
#
?
Nov 9, 2018 23:40
|
|
|
Thermopyle posted:/me waves hands I'm pretty sure I'm the only one working off primary sources, and there's some irony in using a web browser to explain exactly why rest is impossible, broken, or pointless, because it's fundamentally the mechanism behind how people reply to posts
|
|
#
?
Nov 9, 2018 23:43
|
|
|
Suspicious Dish posted:I was paying attention the last two times, but my reservations still apply. You talk about all these hand-wavy things like "oh man what if it could just *find* all the albums because we put some machine-readable data there", but you never explain what this machine-readable data is, or what the standard for it is. That's because _REST IS AN ARCHITECTURAL STYLE_ of which HTTP and HTML are one example. Honestly, I can't trick you into reading the thesis, waving it infront of your face and yelling "here comes the aeroplane"—but given your behaviour it seems appropriate. When your opening argument is "this is impossible" and "according to tef <made up poo poo>", and then follow on to demonstrate that you said neither point in good faith, well, I might as well be on the orange website. Where's that jordan peterson change my mind jpeg
|
|
#
?
Nov 9, 2018 23:49
|
|
|
REST isn't a toolkit, a library, or anything resembling a protocol. It's the name for opening a tab in a new window, It's a set of constraints the web browser put upon the design of HTTP. It's literally about web browsing. If I can't convince you that the notion of "using one client for a variety of services, using self descriptive formats to expose a rich interface over a simpler rpc interface that supports middleware" is useful, what the hell do you do in the web browser anyway?
|
|
#
?
Nov 9, 2018 23:53
|
|
|
people don't want to use one client when programming, tef. they want to go on npm and try to figure out which one of ten libraries that do almost the same thing suits their taste best
|
|
#
?
Nov 9, 2018 23:59
|
|
|
TheFluff posted:people don't want to use one client when programming, tef. they want to go on npm and try to figure out which one of ten libraries that do almost the same thing suits their taste best I know i'm old and out of touch but do you really have to put the boot in? Oh well.
|
|
#
?
Nov 10, 2018 00:09
|
|
|
It's the "if we link resources together clients will magically figure out their relationships". Basically, you're stuck in the "wikidata is really cool" phase of growing up before coming to the realization of "wikidata is actually useless, generic structured data is really hard and the semantic web will never happen". There are still a lot of people working hard on solving this problem, and we're no more closer to a solution than we were in the 1970s. That's what I said was impossible. Browsers work because humans have brains that are good at parsing and munging language (because human brains invented language so they are inherently good at that) which are good at understanding that the "Withdrawls & Deposits" link is the same as the "Account Records" link, because the two are synonyms. But a lot of humans seem to have trouble understanding that "Post" != "Reply", or in your case, "Reply" != "Edit". How on earth do we expect a computer to understand that? Once we take the human brain out of the equation, we're left with basically an addressing model which pushes network detail information to the user and makes it so you can say "hey the albums are located at C:\Windows\System32\NTPASSWD" like Windows 95-era Internet Explorer. You still haven't explained how linking to third-party services is helpful without transferring the full client session. Sure, the YourAlbums link can point to some third-party domain, but which cookies should I pass along? The browser has complicated URL parsing logic to determine which cookie jar to send. Browsers are millions of lines of code of complicated policy built up over time. Do we expect every client library to implement all the arcane undocumented security and other policy changes over the years, that isn't even consistent between browsers? And, yes, I did read the REST thesis but got a very different impression out of it than you, apparently. Also, it's a One Piece Marathon, thank you very much. Naruto is for kids.
|
|
#
?
Nov 10, 2018 00:37
|
|
|
Suspicious Dish posted:OK, so instead of you downloading the schema file, the server sends its schema over at connection time and the client adapts. This was literally the point of SOAP, and one of the parts that they threw out basically as soon as they realized how useless it was. imagine you had a sql client that could render tables with clicky bits. clicking a column would sort by that column or let you add or remove a filter condition on that column. foreign key references would be clicky too and would take you to the table they referenced with the row that contained the foreign key id highlighted or filtered out all other rows or something. also there's a back button to go back to the table you came from and a forward button to go forward again after going back. your client doesn't know anything about the schema of the db other than you're going to get some 'tables' with some 'columns' and 'rows' and 'foreign keys'. any table you can express in sql you can render. that's a restful hateoas interface
|
|
#
?
Nov 10, 2018 01:20
|
|
|
Suspicious Dish posted:It's the "if we link resources together clients will magically figure out their relationships". Basically, you're stuck in the "wikidata is really cool" phase of growing up before coming to the realization of "wikidata is actually useless, generic structured data is really hard and the semantic web will never happen". There are still a lot of people working hard on solving this problem, and we're no more closer to a solution than we were in the 1970s. That's what I said was impossible. what you claim is impossible is exactly how the web has always worked. that's the whole point of fielding's thesis. he wasn't dictating some architectural style; he was describing the most successful implementation of linked resources in the history of civilization also rdf and sparql are a thing that works and is good. we're all just too busy banging rocks together to stop and learn how to leverage them to build a real ecosystem
|
|
#
?
Nov 10, 2018 01:25
|
|
|
the talent deficit posted:imagine you had a sql client that could render tables with clicky bits. clicking a column would sort by that column or let you add or remove a filter condition on that column. foreign key references would be clicky too and would take you to the table they referenced with the row that contained the foreign key id highlighted or filtered out all other rows or something. also there's a back button to go back to the table you came from and a forward button to go forward again after going back. your client doesn't know anything about the schema of the db other than you're going to get some 'tables' with some 'columns' and 'rows' and 'foreign keys'. any table you can express in sql you can render. that's a restful hateoas interface so what you're telling me is that if companies really cared about providing REST interfaces, they would install a copy of phpMyAdmin and call it a day edit: also pulling literally any data out of that page requires the schema of the db. From the other side: "your client doesn't know anything about the records in the JSON blob other than you're going to get some 'dictionaries' with some 'fields' and some 'values'. any table you can express in sql you can json blob. that's a modern restful json api interface" Suspicious Dish fucked around with this message at 02:06 on Nov 10, 2018 |
|
#
?
Nov 10, 2018 01:59
|
|
|
tef posted:"The whole point is making a browser that can work across different services. " SNMP?
|
|
#
?
Nov 10, 2018 02:06
|
|
|
Oh look, it's tef jumping all over a thread in order to demonstrate how tef is the only one who has achieved truly deep comprehension of this thing that tef once looked into. Everybody wave hello to tef.
|
|
#
?
Nov 10, 2018 03:31
|
|
|
Suspicious Dish posted:edit: also pulling literally any data out of that page requires the schema of the db. From the other side: "your client doesn't know anything about the records in the JSON blob other than you're going to get some 'dictionaries' with some 'fields' and some 'values'. any table you can express in sql you can json blob. that's a modern restful json api interface" yeah, what's your question?
|
|
#
?
Nov 10, 2018 03:49
|
|
|
I'm not disregarding the nuanced discussion of the history and meaning of REST; from a practical perspective, being able to pass data between servers and clients using a JSON-based API is wonderful. It allows you to use the same API to pass database info and serverside calculations to a website, phoneapp, or desktop app without changing server code. It allows you to decouple server from client code, which has nice semantic implications for code design, allowing clean separation between GUI code and business logic.
|
|
#
?
Nov 10, 2018 04:03
|
|
|
Suspicious Dish posted:so what you're telling me is that if companies really cared about providing REST interfaces, they would install a copy of phpMyAdmin and call it a day You can get the schema of the DB from the previous page and then write your query.
|
|
#
?
Nov 10, 2018 04:13
|
|
|
tef posted:I'm pretty sure I'm the only one working off primary sources, and there's some irony in using a web browser to explain exactly why rest is impossible, broken, or pointless, because it's fundamentally the mechanism behind how people reply to posts Right (except for the primary sources part), but you keep talking like it's you against the world here, but really SD is the only person who has disagreed with you and then you went off on this tirade like you're the One True Knower.
|
|
#
?
Nov 10, 2018 04:19
|
|
|
Thermopyle posted:Right (except for the primary sources part), but you keep talking like it's you against the world here, but really SD is the only person who has disagreed with you and then you went off on this tirade like you're the One True Knower. I tend to enjoy tef's "desert hermit intoning dire prophecy"-style delivery and it doesn't seem wholly inappropriate if you imagine him addressing the thread but also the ghosts of everyone who has ever given a lovely explanation of REST on hackernews he's not trying to play this role but his shticks include having a really good understanding of several ideas that enough programmers think they can explain back to him despite not understanding, ergo periodically we get queuechat or RESTchat. tef is good and valuable imo and if he authored a book about his areas of expertise I'd purchase it
|
|
#
?
Nov 10, 2018 08:44
|
|
|
The reason more people don't care about REST from an academic level is because the layperson's understanding of REST gets you very, very far for most API development. You will likely never have a manager or a product owner call you out for being only Richardson level 2. Your team or company will never fail because you didn't adhere to all the tenets laid out in Fielding's dissertation. The small handful of times I've seen the more academic details brought up in a real world setting, it's been from completely insufferable pedants doing some weird form of nuclear bikeshedding. It's good to learn your craft, and anyone working on APIs should take an hour to read Fielding's thoughts on REST. But IMO you'll get more utility from dedicating more time to things like stack vs heap allocation, dangers of mutable state, patterns of concurrency, API versioning, etc. I'd take a reliable and performant API over a "properly" designed one if I were forced to choose on just those two facets, and I'd devote more of my time to making sure the former were priorities. luchadornado fucked around with this message at 14:41 on Nov 10, 2018 |
|
#
?
Nov 10, 2018 14:21
|
|
|
rjmccall posted:Oh look, it's tef jumping all over a thread in order to demonstrate how tef is the only one who has achieved truly deep comprehension of this thing that tef once looked into. Everybody wave hello to tef. Yeah. I’m sure this discussion is helping entry level developers land a gig.
|
|
#
?
Nov 10, 2018 14:45
|
|
|
akadajet posted:Yeah. I’m sure this discussion is helping entry level developers land a gig. Considering this is the general question thread not the newbie job thread, I think we're fine.
|
|
#
?
Nov 10, 2018 19:46
|
|
|
I was asking the question so I would know more about something that's used all the time in job postings  I just figured it wan't directly aimed at getting a job so it should go here.Another question, not sure if it should go here or the web dev thread but I've been bombing them with a bunch of stupid questions too so I figure I should spread the pain. Is there a way to connect Cpanel to a remote git repo (bitbucket)? I just want to make sure I have a saved copy of everything in case I accidentally have a payment problem and my site goes poof. Or should I just download everything and do a remote repo from my computer every once in a while when there's a major change?
|
|
#
?
Nov 10, 2018 20:14
|
|
|
E: wrong thread.
|
|
#
?
Nov 10, 2018 21:35
|
|
|
Is "The C Programming Language"* book still the go-to reference when learning C? I did a bit of googling, and its being referenced the most. Is it didactically just that good? It's 30 years old at this point, so I'm a bit surprised there's been no other book that can rival it. * by Brian W. Kernighan and Dennis M. Ritchie mike12345 fucked around with this message at 17:27 on Nov 14, 2018 |
|
#
?
Nov 14, 2018 17:18
|
|
|
mike12345 posted:Is "The C Programming Language"* book still the go-to reference when learning C? I did a bit of googling, and its being referenced the most. Is it didactically just that good? It's 30 years old at this point, so I'm a bit surprised there's been no other book that can rival it. Beej's guide is what I normally see people recommend outside of that book: http://beej.us/guide/bgc/output/html/multipage/index.html It has been on my to-do list for a long time but I've been investing my productivity elsewhere this past year sadly as I don't see much benefit for my portfolio by making stuff with C. The only time I've ever felt liked I needed to know C was when the Cartoon Network people were hiring game developers and their pre-interview coding test required you to reverse a string strictly using C and not C++ with its convenient STL back_inserter. Love Stole the Day fucked around with this message at 17:39 on Nov 14, 2018 |
|
#
?
Nov 14, 2018 17:37
|
|
|
|
| # ? May 19, 2024 07:13 |
|
|
mike12345 posted:Is "The C Programming Language"* book still the go-to reference when learning C? I did a bit of googling, and its being referenced the most. Is it didactically just that good? It's 30 years old at this point, so I'm a bit surprised there's been no other book that can rival it. It is a surprisingly readable book for being a programming book. And its like 100 pages so if you can snag it cheap why not? I haven't read a recent revision so this may not be true anymore, but it doesn't really show modern practices or style. "C Interfaces and Implementations: Techniques for Creating Reusable Software" by Hanson shows how to write modular C, but it doesn't teach the basics.
|
|
#
?
Nov 14, 2018 17:49
|
|
