Swagger and then flask or opposite
Hello,
I'm starting a new poroject who need an API.
I 'm going with flask and swagger.
A simple question: should i start by defining the API with swagger and then generate the python code or the opposite.
Thank for your help.
There are solutions for both approaches:
If you end up preferring to define the API first, I would recommend connexion. You define OpenAPI (new name for Swagger) specification files, and then you do Python code accordingly. I would say that this is the best approach as you can guarantee that whatever code you write afterwards will conform to the specification, that you can provide to whoever wants it. Another advantage is not mixing up core concepts of your logic with the API specification.
Otherwise, flask-restplus does the trick. This is the most common (but not necessarily better) approach, where you write your Python code and the specification is then generated. This is the approach I usually follow in simple use cases.
For information i finally choose the openapi-generator tool that allow me to generate python server stub on Flask/connexion stack and my client lib for Android on top of okhttp.
https://github.com/OpenAPITools/openapi-generator
I was rather satisfied with this choice during my project.
To merge your server stub last version with older one you can dedicated a git branch for raw server stub generation and another one wich you fill with your own code. That way you won't lose your previous version with the code you add to the server stub.
Related
I am building an application that uses two legged authentication. I got an API key and API Secret, but now I am confused.
I am currently storing my api keys and secrets in a .yml file. But I would like to distribute the .app code, which will end up having the .yml file.
But the .app file will contain the .yml, file, which is bad since everyone will be able to see the API key and Secret.
How can I store the API key and Secret such that my application can access the key and secret without the users seeing it?
The answer depends on a few variables:
Is your source included?
Is it possible to use a server to call the API for you? If so, can you also apply restrictions to the call that the server makes?
Is using compiled code for where you store the key an option? If so, is it possible to obfuscate it?
Here are my suggestions for different scenarios from experience:
The source is not included and using a server is an option, and restrictions can be applied, however using compiled code is not an argument
Then use a server to make requests. Let's say you need to make a call to example.com/api/v1, and you want to call a specific function with a specific set of arguments, then you can only allow requests to that specific API, with that specific set of arguments, and that specific function. This way, it means nothing to a potential attacker since it only calls to one function and nothing else.
The source is not included, using a server is not an option, and compiled code is not an option either
Well, there's not much you can do, obfuscation is your best shot. The best way to do something like this is to hide it deep within your code, and make it obscure, etc., etc., etc.,
The source is included, using a server is not an option, but you can use compiled code
Use really obfuscated assembly and don't share the source for that if you can. For instance, you can have red herring instructions, and just like before, you should hide it deep in your code.
The source is not included, using a server is not an option, but you can use compiled code
For this it's the same as above, since the source for the assembly wouldn't be included
If I didn't list your scenario here, then feel free to comment and I'll edit my answer
While I consider the existing answer technically correct, it may be wroth pointing out that there are some security issues with hardcoding api keys in distributed software.
The nature of an API key is volatile, it is not designed to last forever.
What would happen if the API key is invalidated? Wouldn't that render all distributed software useless then?
And what would happen if the API key has write privileges and is compromised? How could you distinguish between legit and malicious writes?
Even though I understand the overhead, a scenario were the end user can set dedicated keys, obtained by the end user itself, and a way to replace that initial key, would help with above two questions.
One of the API Key features is to be used by a machine that acts on behalf of a user, but if all the users are the same, this feature becomes meaningless.
I've searched internet but couldn't find a good solution. I'm looking for something that pretty specific - a golang copy of aiohttp_swagger.
That is a Python package which does magical things. In the endpoint handler method, one write some comment code and it'll be automatically parsed and generates swagger documentation. When the server is up and running, a special URL /api/doc handler will be inserted into the server where people can see it live.
I understand it's tied into the implementation of aiohttp framework and the way Go is used, web framework is not as popular (not using one myself), but I still like that solution very much and would like to find something in the Go land.
So my question is a bit open I guess: is there an equivalent (or rough) of aiohttp_swagger package in Go?
go-swagger does it based on doc comments: https://goswagger.io/generate/spec.html
go-restful has a builder for creating swagger 2.0 documents: https://github.com/emicklei/go-restful-openapi
I read tons of documentations, but I cannot find e real full-working example of a Python Google App Engine that simply gives a Login/Logout button to the GOOGLE PLUS authentication system.
Probably this is due to my limited understanding.
My need is to use the info on the backend side in order to give customized contents.
Maybe that's because apparently Google+ Sign-In is being phased out, replaced by Google Sign-In: https://developers.google.com/identity/sign-in/web/quick-migration-guide.
If you're just starting it's probably better to go directly to the newer method (or maybe check if other alternatives might be available/better fitted for your app: https://developers.google.com/identity/) then re-focus your searches accordingly.
Also very important (for most if not all newer authentication methods) - pay attention to the implementation guides:
no code example will be working out of the box as various application-specific service configurations are usually needed as well
no code example will be complete since it needs to incorporate application-specific keys or other pieces of info that can only be obtained from the above service configurations
At the end I solved the problem using simpleauth.
https://simpleauth.appspot.com/
Surely the easyest and efficient way to add oauth2 authentication in your website.
Any pointers, advice on implementing a REST API on App Engine with Python? Using webapp for the application itself.
What I currently know is that I can:
hack up my own webapp handlers for handling REST-like URIs, but this seems to lose its elegance for larger amounts of resources. I mean, it's simple when it comes to temperature/atlanta, but not so much* for even a rather simple /users/alice/address/work (though do keep in mind that I'm not saying this after having implemented that, just after spending some time trying to design an appropriate handler, so my perception may be off).
use the REST functionality provided by one of the bigger Python web frameworks out there. I have some unexplainable sympathy towards web2py, but, since it's not used for the project, bundling it with the application just to provide some REST functionality seems.. overkill?
(Huh, looks like I don't like any of these approaches. Tough.)
So here's me asking: what advice, preferably based on experience, would you have for me here? What are my options, is my view of them correct, did I miss something?
Thanks in advance.
I had a similar issue. Wanting to quickly get my DataStore exposed via REST to WebApps.
Found: AppEngine REST Server.
I have only used it lightly so far, but it certainly appears to be very useful with a small amount of work. And it does use webapp as you suggested.
ProtoRPC is bundled with the SDK, and it is robust and actively developed (however experimental). Although I think the source code itself is a little convoluted, the feature-set is pretty complete and it was made by someone with experience in creating this kind of library. It supports transmiting using JSON, ProtocolBuffer and URL-encoded formats.
Also, you can create APIs that work on the server side and client side -- it defines a 'message' protocol with implementations in Python and JavaScript. I used other "RESTful" Python libraries, but no other provided this consistency out of the box.
Here is the project page and here is the mailing list.
Edit: maybe their documentation is lacking some keywords, but just to be clear: one or the purposes of ProtoRPC is to provide a solid foundation to create REST services.
I'm just starting out with Python and have practiced so far in the IDLE interface. Now I'd like to configure Python with MAMP so I can start creating really basic webapps — using Python inside HTML, or well, vice-versa. (I'm assuming HTML is allowed in Python, just like PHP? If not, are there any modules/template engines for that?)
What modules do I need to install to run .py from my localhost? Googling a bit, it seems there're various methods — mod_python, FastCGI etc.. which one should I use and how to install it with MAMP Pro 1.8.2?
Many thanks
I think probably the easiest way for you to get started is to work with something like Django. It's a top-to-bottom web development stack which provides you with everything you need to develop and run a backend server. Things can be very simple in that world, no need to mess around with mod_python or FastCGI unless you really have the need.
It's also nice because it conforms to WSGI, which is a Python standard which allows you to plug together unrelated bits of reusable code to add specific functionality to your web app when needed (say for example on-the-fly gzip compression, or OpenID authentication). Once you have outgrown the default Django stack, or want to change something specific you can go down this road if you want.
Those are a few pointers to get you started. You could also look at other alternative frameworks such as TurboGears or paste if you wanted but Django is a great way to get something up and running quickly. Anyway, I'm sure you'll enjoy the experience: WSGI makes it a real joy knocking up web apps with the wealth of Python code you'll find on the web.
[edit: you may find it helpful to browse some of the may Django related questions here on stack-overflow if you run into problems]
You asked whether HTML is allowed within Python, which indicates that you still think too much in PHP terms about it. Contrary to PHP, Python was not designed to create dynamic web-pages. Instead, it was designed as a stand-alone, general-purpose programming language. Therefore you will not be able to put HTML into Python. There are some templating libraries which allow you to go the other way around, somewhat, but that's a completely different issue.
With things like Django or TurboGears or all the other web-frameworks, you essentially set up a small, stand-alone web-server (which comes bundled with the framework so you don't have to do anything), tell the server which function should handle what URL and then write those functions. In the simplest case, each URL you specify has its own function.
That 'handler function' (or 'view function' in Django terminology) receives a request object in which interesting info about the just-received request is contained. It then does whatever processing is required (a DB query for example). Finally, it produces some output, which is returned to the client. A typical way to get the output is to have some data passed to a template where it is rendered together with some HTML.
So, the HTML is separated in a template (in the typical case) and is not in the Python code.
About Python 3: I think you will find that the vast majority of all Python development going on in the world is still with Python 2.*. As others have pointed out here, Python 3 is just coming out, most of the good stuff is not available for it yet, and you shouldn't be bothered about that.
My advise: Grab yourself Python 2.6 and Django 1.1 and dive in. It's fun.
Django is definitely not the easiest way.
check out pylons. http://pylonshq.com/
also check sqlalchemy for sql related stuff. Very cool library.
On the other hand, you can always start with something very simple like mako for templating. http://www.makotemplates.org/