Is python a good language for building a RestAPI? Personally I don't have any experience with python yet, but what I've gathered, is that python is great for scripting, and big data.

I have a bit of knowledge about Node.js, and I really like the structure, and it's so easy to make an API using express.js.

I've already read a bunch of articles about it, but I'd like to know what the community feels about the two languages?

Both are equally good to build APIs with.

does it have to be rest?
graphQL is the successor of REST and easier and versatile to use than REST. And with https://www.apollographql.com/ or https://prisma.io you get a good server and api framework.

Here an intro
www.graphql.com

Dotnetcore is good for apis and generating a swagger playground if you fancy trying your hand at c#

@heyheni Well it doesn't exactly HAVE to be rest, but there are just many factors in my life, that makes it optimal for it to be rest.

@gruff dotnetcore is amazing as long as it just works, but I have never seen a language/framework more horrible when it comes to debugging errors. And of course all the things that just doesn't work...

@KasperNS with graphQL you get SOAP, REST and GraphQL at the same time. The main advantage of graphQL is it fetches only the specific data you need, which makes your app faster by using less transfer bandwith.

@heyheni I'm in no way arguing that GraphQL is better, what I mean is that for me personally, it makes more sense to develop it using normal rest.

Right now I'm a student, and we're learning normal Rest. At the same time I'm self-learning a lot of DevOps stuff, since that's what I want to work with when I'm done with school next year. I also want to know a lot more about security, so that's another thing I have to read up on a lot.

That along with just regular life, I have quite many things on my plate, so having to learn GraphQL on top of that, it'll just be a bit too much for me.

I had to work with this once --> https://django-rest-framework.org// but I found myself more comfortable and productive by building my own tools for converting JSON data into Python models. Personally for Restful APIs I rather to use other languages like JS or PHP. Never tried Graphql but am very intrigued about it.

Python is perfectly viable for REST API's. The most popular libraries are Django, Flask and Pyramid (bit less popular but still good).

Developing in Pyramid myself now, but Flask is a godsend if you just want to setup something quickly.

I need to dive into graphql a bit I admit, but how is REST unable to return only the data you request? I have thousands of automated REST requests a day that pull only a specific set of data on each one. What am I missing?

@bahua I think the point is that in REST, when you call an endpoint, you need to get all the data that that endpoint returns, whereas in GraphQL, you can make one endpoint, capable of returning (just to exaggerate) 1000 properties, but specify each time, exactly what properties you need returned

@bahua So yeah, it's not that REST can't do it, it's that you need to have many different endpoints, depending on what data you want returned

@KasperNS

Again I'm confused. Are we just assuming that people cannot provide CGI arguments?

@bahua I may just be stupid now, but the term 'cgi arguments' is not something I've heard before.

And to be clear, I'm in no way an expert on GraphQL, never worked with it, but I think this article gave me a pretty good view of what it can do:

https://malcoded.com/posts/...

@KasperNS really? were running dotnetcore in production without issues. The main gotcha that stumps people is if you do dotnet run it will run a production version and not the development version. You need to pass in the aspnetcore_environment=Development environment variable.

@gruff Yeah I just made a school project, with the backend being in dotnet core 2.1, with the entity framework. And here's a short list of my biggest problem with the platform:

- If you want to use SSL, you need to make a .pfx document, and just overall you need to code the ssl implementation in. If we compare it to node.js hosted on nginx, you just implement it on the server. No need for the codebase to worry about that.

- Sometimes, dotnet just returns a CORS error instead of a regular 500 status code. Like wtf?

- At some point our .csproj file got so fucked up, that the program f'ed up completely. Had to manually sit and edit it, to get it to work.

And that's just the major problems we had. Other than that I've really started to hate Microsoft, and I'll do a lot, to avoid using something that they've created. So. Many. Stupid. Problems.

If you want to build a REST API, it doesn't matter which language you choose, as long as you can handle Http stuff. It's an architecture style, it doesn't give constraints regarding the language or framework.

Using an established web framework helps alot and for python there is Django and Flask if I'm not wrong.

So feel free to use python or any other language you feel comfortable with.

@KasperNS

The common gateway interface, or CGI, enables interactivity between the client and the server. The most obvious form of this interaction from the client's standpoint is CGI variables, passed to the server in the form of key/value pairs in the URL's QUERY_STRING variable.

https://nuts.cans/?name=pogo

This structure has been heavily in use for about as long as the hypertext transfer standard has existed, and is a critical part of the interaction with any REST API.

They are both cool for building API. Express and mongoose makes building stress free

@bahua ahh okay, well then I do know what cgi parameters are, just didn't know that was the term for it 😅

But by then I just think it becomes a matter of personal opinion. From what I've seen, the code looks a lot more organized and well thought out, when using GraphQL, at least when it comes to fetching only what you want. But yeah that's just my opinion.

@Rikan while you're not in any way wrong, there are still a few things to consider between languages. Like how many requests they can get per second, and how fast they respond to those requests.