In djangorestframework, there is a browsable api. But how do I show a user an entire bird's eye view of all the possible API calls that he/she can make? I can only see one at a time right now and the user would have to already know the correct URL beforehand
i.e.,
http://localhost:8000/users
http://localhost:8000/books
http://localhost:8000/book/1/author
Thank you!
The answer is as Klahnen said. Use this:
https://django-rest-swagger.readthedocs.io/en/latest/
It works out of the box for me and it is exactly what I was hoping for.
I still maintain, though, that the term browsable API implies that there is a table of contents available for consumers of your API to see. This app is a lifesaver and perhaps it should be included!
Django-Rest-Swagger as mentioned in the accepted answer is no longer maintained.
This is a good alternative
https://github.com/axnsan12/drf-yasg
Django-Rest-Swagger doesn't support OpenAPI 3.0 and is unlikely to support it soon, so if you want an actively maintained library that supports OpenAPI 3.0 then you should use drf-spectacular. It mostly works out of the box, and you can customize it a lot.
A side note:
Your api client needs access to the internet so that it gets the swagger UI or ReDoc from CDNs. Alternatively you can serve those static files from your service with an optional additional package, the drf-spectacular-sidecar
Related
I'm using django and I want to integrate stripe using the abstraction layer dj-stripe.
From what I understand from the documentation, ElementJs with Payment Intent is the preferred way to allow users to enter their payment details. see https://dj-stripe.dev/stripe_elements_js/
However, there is no documentation on how to connect dj-stripe with stripe.js. The first step of the usage documentation in dj-stripe already assumes payment methods have been connected (https://dj-stripe.dev/usage/subscribing_customers/). I looked through the code of dj-stripe and it seems to have Payment Intent classes, but I can't figure out how to use them.
How can I generate a client secret for customers created in dj-stripe that can then be used in stripe.js? (Or if I'm not on the right path, what should I do instead to allow adding payment details to be used in dj-stripe)
dj-stripe is a Python backend framework, and theoretically it should work with any frontend including pure stripe.js. You should follow Stripe official Doc and adapt. They also have an example project in Python (not Django though).
I'm documenting a django project that use DRF. I already generated a dynamic API schema using openapi and redoc. Very cool solutions
However, I miss the permissions part in all of this
I have a lot of permissions (permission_classes) in the viewsets and some functions. Do you know any solution to include the permission in the schema, or in a documentation in general?
Going further, how do you document permissions in a APIs in general?
I already have an idea: include the permissions in a custom description in the schema, but it's still dirty
Thanks. José.-
PS: Sorry for the poor english
DRF is in the process of deprecating the use of the coreapi package, however currently there is not easy way within that solution to get security schemas to be added to your documentation.
However there is an alternative https://drf-yasg.readthedocs.io/en/stable/ this tool claims to support extracting these values (but I personally have not used it for that yet).
I am trying to build the eCommerce store by using Slatwall and lucee. Slatwall is the ColdFusion based eCommerce framework. The admin part is working fine. But I could not create the user side. I also referred the slatwall documentation. But no luck I couldn't seen any clear example and document for adding the front end on slatwall. If anyone knows help me please?
Slatwall frontend document
As OP says, SlatWall has excellent $upport, that's where they make a living. You now have three choices for a front end:
1) Slatwall latest versions have their own integrated CMS now. I'd recommend you export your product info, install the latest Slatwall, import the data back in.
2) Load MuraCMS, an Open Source Content Management (i.e. front-end) system that has integration to Slatwall (or the other way round, IIRC)
3) Roll your own in ColdFusion after learning ins and outs of the Slatwall api. Not recommended unless you're already CF experienced and have some previous experience with an api, any api.
For completeness I am going to answer this question even though its months old, for anyone else that views this.
You have a couple options here but the easiest way:
There is a complete example of a fully implemented Slatwall site including product listing pages, shopping-cart, and checkout included with Slatwall.
You may view the sample site by visiting http://{yourslatwallsite}/meta/sample
On the sample site, you can choose from the menu to view your products, add them to your cart, or checkout. Make sure your products are both active and published in the admin or you will not see them on the sample site. If you go through the .cfm pages that makeup the sample site, there are many examples documented (as comments in the code). Note that the actual .cfm files will be stored in /public/views/xxx.cfm and the meta folder just references them. /public/views/templates/slatwall-productlisting.cfm for example has complete examples on listing products on the frontend.
The sample site is powerful enough that you could restyle it and use it as your store
I am designing an API using WSO2AM 2.0
My service is like : http://190.100.10.10:9000/abc/xyz/doPost<br>
I want to replace /abc/xyz/doPost by /<MY_CUSTOM_PATH>/doPost
How can I make a custom URL pattern to hide my original URL path from the service?
Like: http://<WSO2AM_GENERATED_HOST>/WSO2AM_CONTEXT/WSO2AM_VERSION/<MY_CUSTOM_PATH>/doPost
I have searched the docs, but I am not able to find any related tutorial.
If I put /abc/xyz/doPost it will get appended to the WSO2AM generated hostname.
What is "EDIT SOURCE" in the image below? Can it be used to do what I want? If YES, How??
There aren't anything like WSO2AM_CONTEXT or WSO2AM_VERSION. You can provide any value for the context and version. Version can be String, numbers, etc.
In your case, you can use abc as context and xyz as the version.
That is exactly the kind of URL you would get in WSO2 API Cloud: http://your.custom.url/api-name/version/context. See this tutorial for details: https://docs.wso2.com/display/APICloud/Customize+the+API+Store+and+Gateway+URLs
It might not be complicated...
In publisher interface, when you add/edit an API, in "Implementation" screen, just configure WSO2 APIM to point to "http://190.100.10.10:9000/abc/xyz" - this way, "/abc/xyz" will not be visible to your clients.
So in this case,
http://<WSO2AM_GENERATED_HOST>/WSO2AM_CONTEXT/WSO2AM_VERSION/doPost
will point to:
http://190.100.10.10:9000/abc/xyz/doPost
If you wanted to add additional custi=om paths, in the "Design" screen you attached, you can also add your "(MY_CUSTOM_PATH)/doPost" path there.
This way
http://<WSO2AM_GENERATED_HOST>/WSO2AM_CONTEXT/WSO2AM_VERSION/<MY_CUSTOM_PATH>/doPost
will point to:
http://190.100.10.10:9000/abc/xyz//<MY_CUSTOM_PATH>/doPost
(However, your backend services should also have "//doPost" implemented)
I have been struggling with choosing a methodology for creating a RESTful API with Django. None of the approaches I've tried seem to be the "silver" bullet. WAPI from http://fi.am is probably the closest to what I would like to accomplish, however I am not sure if it is acceptable in a true RESTful API to have parameters that are resource identifiers be in the querystring instead of in a "clean" URL format. Any suggestions for modifying WAPIs RestBinding.PATTERN to "clean" up the URLs? Another option I've explored is Django-Rest-Interface. However this framework seems to violate one of the most important pieces I need, and that is to include the full resource URL for references to other resources (see http://jacobian.org/writing/rest-worst-practices/ Improper Use of Links). The final option is to use django-multiresponse and basically do it the long way.
Please offer me your best advice, especially people that have dealt with this decision.
For Django, besides tastypie and piston, django-rest-framework is a promising one worth mentioning. I've already migrated one of my projects on it smoothly.
Django REST framework is a lightweight REST framework for Django, that
aims to make it easy to build well-connected, self-describing RESTful
Web APIs.
Quick example:
from django.conf.urls.defaults import patterns, url
from djangorestframework.resources import ModelResource
from djangorestframework.views import ListOrCreateModelView, InstanceModelView
from myapp.models import MyModel
class MyResource(ModelResource):
model = MyModel
urlpatterns = patterns('',
url(r'^$', ListOrCreateModelView.as_view(resource=MyResource)),
url(r'^(?P<pk>[^/]+)/$', InstanceModelView.as_view(resource=MyResource)),
)
Take the example from the official site, all above codes provide api, self explained documentation (like soap based webservice) and even sandboxing for testing. Very convenient.
Links:
http://django-rest-framework.org/
I believe the recently released django-piston is now the best solution for creating a proper REST interface in Django. django-piston
Note: django-piston seems to no longer be maintained (see comments below)
django-tastypie is a good way to do it, their slogan: "Creating delicious APIs for Django apps since 2010" is pretty comforting ;)
You could take look at django-dynamicresponse, which is a lightweight framework for adding REST API with JSON to your Django applications.
It requires minimal changes to add API support to existing Django apps, and makes it straight-forward to build-in API from the start in new projects.
Basically, it includes middleware support for parsing JSON into request.POST, in addition to serializing the returned context to JSON or rendering a template/redirecting conditionally based on the request type.
This approach differs from other frameworks (such as django-piston) in that you do not need to create separate handlers for API requests. You can also reuse your existing view logic, and keep using form validation etc. like normal views.
I don't know if this project can be useful for you, but sending a link can hardly hurt. Take a look at django-apibuilder , available from http://opensource.washingtontimes.com/projects/django-apibuilder/ . Perhaps it can be useful?
/Jesper
Have a look at this RestifyDjango.
Somewhat related are Django XML-RPC and JSON-RPC.
https://github.com/RueLaLa/savory-pie
Savory Pie is a REST framework that supports django.
I would suggest you look into Django Rest Framework (DRF), play around with this and see if it suits your requirements. The reason I recommend DRF is because it makes making the API views really simple with the use of GenericAPIView classes, Mixin Classes and Mixed in Generic views. You can easily make use of tried and tested design patterns for making your API endpoints as well as keeping your code base neat and concise. You also DRY when writing your code which is always great. Your API views are literally 2-3 lines long.
You can checkout this tutorial http://programmathics.com/programming/python/django-rest-framework-setup/ that begins from setting up your environment to going through the different ways to make your RESTful API using the django rest framework.
Disclaimer: I am the creator of that website.