|
Nolgthorn posted:I've been hearing rumblings that REST is dead. That the concept in practice doesn't work very well, that no consistency exists between APIs and that it's basically a crap shoot where the only value derived from it are descriptive urls. But those urls could be replaced easily by descriptive names, in fact names could be those urls or something even more suitable. REST is not dead and probably won't be dead for the foreseeable future. It's great for 2 completely separate servers to communicate with each other in an expected manner. The point of an API is that the behavior is simple and expected from the documentation. Most REST APIs really only need GET or POST. PUT, PATCH, DELETE, POST are all synonymous in a way (I am oversimplifying). Because they don't mean anything unless the implementor makes them mean something. (Very few APIs I've worked with are more than GET, POST and PUT - there's a scary API I write to that deletes data with a GET call). What you're saying is the future sounds a lot like GraphQL, which I really like the idea behind. But it's going to take a big shift to get there. And companies who have APIs probably have 100s or 1000s of clients so making a sudden switch might not always be possible. GraphQL sounds great internally. Externally, it does as well, but there is corporate buy-in then getting all of your customers to update their knowledge base as well.
|
# ? Sep 10, 2017 20:19 |
|
|
# ? May 16, 2024 16:31 |
|
Thinking more in the realm of new apis not in upgrading old ones. Error codes too, it seems like they aren't implemented in any kind of uniform or expected way. You can try and GET a resource that's behind authentication and if you're not authenticated you can expect any of a huge number of possible error codes. I understand there is some agreement about what you should receive but I think it'd be a lot simpler if we all admitted that it is on a per API basis, realistically. Some will return 404 some will return something else. I'd prefer something like. code:
I've been building APIs for a while. I know they're not changing soon. But I also am getting disillusioned.
|
# ? Sep 10, 2017 22:49 |
|
Nolgthorn posted:
That's more an implementation issue and not necessarily a shortcoming of REST though, right? I mean there's definitely a standard for what should be returned in that scenario
|
# ? Sep 10, 2017 23:44 |
|
How would an alternative to REST solve that issue?
|
# ? Sep 10, 2017 23:49 |
|
ROFLburger posted:That's more an implementation issue and not necessarily a shortcoming of REST though, right? I mean there's definitely a standard for what should be returned in that scenario It seems to depend who you ask. https://docs.microsoft.com/en-us/rest/api/storageservices/common-rest-api-error-codes https://developer.springcm.com/guides/rest-api-response-and-error-codes https://www.fusioo.com/guide/api-status-error-codes https://actionstep.atlassian.net/wiki/spaces/API/pages/13140251/Error+Codes Best resource I found looked like a flow chart. I think only communication errors should return a error code, if the software is communicating correctly then just let me communicate with the software and leave the code book out of it.
|
# ? Sep 10, 2017 23:49 |
|
Honestly, I'm glad that REST APIs are around. Working with SOAP/XML endpoints was, and is a huge loving pain in the rear end.
|
# ? Sep 11, 2017 04:42 |
|
Nolgthorn posted:But I get it. These transmission frameworks are too complicated, in a perfect world I'd be able to simply run a function on a different server. The closest we can come to something so simple is a single parameter in the shape of an object. Congratulations, you've proposed RPC over HTTP.
|
# ? Sep 11, 2017 13:29 |
|
Most of what we call REST isn't remotely close to REST anyway, it's just using standard HTTP semantics in developing APIs rather than shoving them into a custom request protocol.
|
# ? Sep 11, 2017 14:33 |
|
RESTfulish
|
# ? Sep 11, 2017 15:25 |
|
Thermopyle posted:RESTfulish
|
# ? Sep 11, 2017 15:44 |
|
I prefer Resty.
|
# ? Sep 11, 2017 16:51 |
|
edit - I may use querySelectorAll with that tag. Seems to work without errors, just hope I can work with it to grab the info. Using Greasemonkey on YouTube. Possibly really simple problem I'm just not seeing the problem. code:
LP0 ON FIRE fucked around with this message at 17:58 on Sep 11, 2017 |
# ? Sep 11, 2017 17:40 |
|
Are you relying on the $ that's present in the debugger console to be present when the console isn't open (it's probably not!) or does YT actually use jQuery? You can use https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector in place of $. var $ = $ || document.querySelector; is good boilerplate for Grease/Tampermonkey
|
# ? Sep 11, 2017 18:03 |
|
Munkeymon posted:Are you relying on the $ that's present in the debugger console to be present when the console isn't open (it's probably not!) or does YT actually use jQuery? Thank you! Yes YT not using jQuery is probably my problem. I shouldn't just assume stuff like this.
|
# ? Sep 11, 2017 18:35 |
|
lol if you don't always run your jQuery code in some form of var $ = jQuery;
|
# ? Sep 12, 2017 05:10 |
|
My greasemonkey boilerplate:JavaScript code:
It's not quite JavaScript code:
Wheany fucked around with this message at 12:40 on Sep 12, 2017 |
# ? Sep 12, 2017 12:38 |
|
This jQuery talk got me thinking...I bet I haven't used jQuery in over a year! Modern web development with transpiling and poo poo is doing some good in the world.
|
# ? Sep 12, 2017 14:38 |
|
Wheany posted:My greasemonkey boilerplate: Oh yeah, querySelectorAll is what $ does in the console.
|
# ? Sep 12, 2017 16:00 |
|
Thermopyle posted:This jQuery talk got me thinking...I bet I haven't used jQuery in over a year! I still use it every single day at work. And yesterday I ran into an issue where a third-party app was importing it's own (reeeeeally old) version of JQuery on some client store, so none of my code was working
|
# ? Sep 12, 2017 17:22 |
|
I was looking taking a look at some tools today, namely Express, Sequelize, and Knex and my brain is exploding a little bit I'm not really getting the difference between Express and an ORM. What is Express used for and what is an ORM used for? Knex is a SQL Query Builder, but it returns promises, so is it an ORM as well? Could I build an full stack app with just react and sequelize? teen phone cutie fucked around with this message at 23:23 on Sep 12, 2017 |
# ? Sep 12, 2017 23:00 |
|
Grump posted:I was looking taking a look at some tools today, namely Express, Sequelize, and Knex and my brain is exploding a little bit Sequelize and Knex are both ORMs. They let you interact with a database like Postgres or MySQL using straightforward JavaScript, instead of SQL. Express is a minimal web framework. You can use it, for example, to route requests that are made from a client to a server. How do you determine what to serve when a request is sent to "/home" versus "/api/v1/users"? Express doesn't interact with the database. So, you might have an api endpoint like "api/v1/users" that Express understands. Under that registered route, you can write some code in JavaScript that leverages Sequelize/Knex to do something to a database, like create a user or find one or what not. You could also use Hapi, Koa, etc., but Express seems to be most common and is pretty straightforward to use. React is the view layer that would be interacting with all that stuff. From React, you send HTTP requests. Express helps them easy to pull apart, then Sequelize/Knex lets you do stuff to a database based on what the request is specifying. If you're just building a back-end API, you don't need React.
|
# ? Sep 12, 2017 23:20 |
|
The Dark Wind posted:Sequelize and Knex are both ORMs. They let you interact with a database like Postgres or MySQL using straightforward JavaScript, instead of SQL. Thanks for that. I guess now I'm just confused on what exactly is the point of frameworks like Express, Hapi, etc and what exactly they're doing Why can't I run some Sequelize function on a button click and just interact with my database with just a view layer? Sorry i just have a really bad understanding of how back-end code works teen phone cutie fucked around with this message at 23:34 on Sep 12, 2017 |
# ? Sep 12, 2017 23:31 |
|
Because that would expose your database server to the public internet.
|
# ? Sep 13, 2017 00:20 |
|
Thermopyle posted:This jQuery talk got me thinking...I bet I haven't used jQuery in over a year! Yeah, we have a reference to it in my last big project because someone used a UI widget that required it and it looked like too much to get it out at the time. But as far as the day to day, haven't hosed w it in a while.
|
# ? Sep 13, 2017 11:54 |
|
Grump posted:Thanks for that. I guess now I'm just confused on what exactly is the point of frameworks like Express, Hapi, etc and what exactly they're doing Because then somebody will enter x'; DROP TABLE users; -- into your login form and you will be sad.
|
# ? Sep 13, 2017 15:50 |
|
Grump posted:Thanks for that. I guess now I'm just confused on what exactly is the point of frameworks like Express, Hapi, etc and what exactly they're doing Anyone with access to that view layer would be able to run whatever queries they want - delete your blog posts, change the pictures to goatse, whatever. The backend sits between the front end and the database and is the arbiter of business logic that you wouldn't want the frontend to be in control of. Sure, the frontend can enforce whatever behavior you want, but it is ultimately useless against someone with dev tools and a rest client. So two of the biggest reasons, among plenty of others, would be security and application logic.
|
# ? Sep 13, 2017 20:31 |
|
I stopped making web apps long ago, I just set up a user facing phpmyadmin and it's practically the same thing.
|
# ? Sep 14, 2017 18:15 |
|
Trip report: None of the things here I've tried work in Typescript. Ie 'Property find does not exist on type 'number[]'. Same with includes etc.
|
# ? Sep 16, 2017 01:16 |
|
Dominoes posted:Trip report: None of the things here I've tried work in Typescript. Ie 'Property find does not exist on type 'number[]'. Same with includes etc. You have to specify that when running (or whatever you're using to run) TypeScript, specifically you want this: code:
As you're likely not running the TS binary directly, post your Webpack config (or whatever you're using to run TypeScript).
|
# ? Sep 16, 2017 02:13 |
|
IIRC that will make it not work on browsers that don't support ES6. Is that correct?JavaScript code:
|
# ? Sep 16, 2017 02:35 |
|
Yes, you need a "shim" (just a library that implements ES6 features in older JS) like "es6 shim": https://github.com/paulmillr/es6-shim For configuring TypeScript the awesome-typescript-loader docs say to add a tsconfig.json file. Put it in the same directory as your webpack config, and you shouldn't need any of the options for the loader itself, just add the "target" thing to "compilerOptions": https://github.com/s-panferov/awesome-typescript-loader/blob/master/README.md
|
# ? Sep 16, 2017 02:47 |
|
I think Typescript is the best thing to happen to Javascript since ES2015 but lately they've been letting me down with the part of it that really mattered to me which was client side compilation. It can compile to ES5 but it cannot compile to a single file. It used to be able to. That functionality has languished and now you need a second compilation step in order to get the code where it needs to be. I was using Rollup to do that which was annoying but still manageable. Now that I see support for Vue, or just about anything which isn't Angular falling by the wayside I've had to stop using Typescript. Which is such a shame because it was one of my favourite tools for a long time.
|
# ? Sep 16, 2017 14:56 |
|
Still no ES6 alternative for `pick`... ? code:
|
# ? Sep 16, 2017 15:04 |
|
Nolgthorn posted:I think Typescript is the best thing to happen to Javascript since ES2015 but lately they've been letting me down with the part of it that really mattered to me which was client side compilation. It can compile to ES5 but it cannot compile to a single file. How is client side compilation a deal breaker? There are a ton of industry standard tools for bundling files, TypeScript shouldn't be trying to do their own.
|
# ? Sep 17, 2017 04:26 |
|
All that s TypeScript chat made me wonder: has anyone used Flow? I've never used either, but sometime soon I want to get type checking going on at work.
|
# ? Sep 17, 2017 05:23 |
|
Lumpy posted:All that s TypeScript chat made me wonder: has anyone used Flow? I've never used either, but sometime soon I want to get type checking going on at work.
|
# ? Sep 17, 2017 14:30 |
|
Skandranon posted:How is client side compilation a deal breaker? There are a ton of industry standard tools for bundling files, TypeScript shouldn't be trying to do their own. Because Typescript is a compiler. You only need another compiler if you wanna do client side compilation, something it used to do and used to do a lot better than Browserify or Webpack. "Industry standard" doesn't generally describe technologies that are only a couple of years old, as well.
|
# ? Sep 17, 2017 20:58 |
Nolgthorn posted:Because Typescript is a compiler. You only need another compiler if you wanna do client side compilation, something it used to do and used to do a lot better than Browserify or Webpack. "Industry standard" doesn't generally describe technologies that are only a couple of years old, as well. Is there any tool in the frontend side of things that actually qualifies for your definition of "industry standard"?
|
|
# ? Sep 18, 2017 00:18 |
|
gmq posted:Is there any tool in the frontend side of things that actually qualifies for your definition of "industry standard"? ...the browser?
|
# ? Sep 18, 2017 01:59 |
|
|
# ? May 16, 2024 16:31 |
|
Nolgthorn posted:I've been hearing rumblings that REST is dead. That the concept in practice doesn't work very well, that no consistency exists between APIs and that it's basically a crap shoot where the only value derived from it are descriptive urls. But those urls could be replaced easily by descriptive names, in fact names could be those urls or something even more suitable. i'm not going to argue that 'REST' apis in the wild aren't generally tremendously bad, but i don't think there's any other superior protocol out there to replace it. REST, done properly, has a ton going for it that is a lot of work to replicated for one, it's use of http as a protocol means it's instantly cacheable and proxyable. for another, it's human readable so you can poke and prod and experiment with an api with standard tools like curl or a browser. third, it wasn't so much designed as discovered as having evolved in the wild. a REST api is just a webpage, really, altho instead of serving html you serve json or xml or whatever. i think that's the part everyone misses about the roy fielding thesis. he wasn't designing a new way to write apis he was describing what was and still is the most successful protocol in history, the world wide web can you replace it with something like graphql or soap or json-rpc or gRPC? yeah, you can. should you? maybe. if your api is an internal thing that has limited functionality and you want strict client/server interaction with all your types and message flows designed up front you probably don't need REST and you're better served by json-rpc or gRPC. however, if your API needs to talk to multiple clients not all of which are controlled by you and you have multiple consumers that might have very different needs, REST is probably the most flexible way to deliver just that
|
# ? Sep 18, 2017 06:06 |