I have written the logic for a backend e-commerce REST API, and I have documented it here:
https://app.swaggerhub.com/apis-docs/chris-larham-1983/e-Commerce_Registration_Customers_Addresses_Orders/0.1#/. I would like to include this specification in my project that is deployed on Heroku so that the project and documentation are in one place.
I have configured the Heroku database, populated the 'customers', 'orders', 'products', and 'addresses' table with sample data, and the specified endpoints are working as specified in the document - for example, https://codecademy-e-commerce-rest-api.herokuapp.com/api/products.
So far I have tried downloading the documentation from within my Swagger Hub account in 'html', 'html2', and 'dynamic html' formats, as I thought I would just include a .html document in my project. However, these downloaded documents do not closely resemble the documentation as linked above; the formatting is very different and does not look as professional.
Does anybody know I could include my Swagger Hub API definition in my project so that the documentation and project are both hosted on Heroku?
Thanks in advance for any help/pointers to tutorials.
After a couple of hours of searching and configuring, I have solved this problem thanks to an npm package called swagger-ui-express. This package can be found here: https://www.npmjs.com/package/swagger-ui-express.
I downloaded my API specification in the format JSON resolved and added it to my project as a file named swagger.json. Then I followed the configuration information in the swagger-ui-express documentation, uploaded to heroku, and it worked!
The lines of code I added in index.js were:
const swaggerUi = require('swagger-ui-express');
const swaggerDocument = require('./swagger.json');
app.use('/api-docs', swaggerUi.serve, swaggerUi.setup(swaggerDocument));
I hope this helps somebody in the future :)
Related
Some weeks ago I installed drf-spectacular. Everything was working properly until I enabled versioning in DRF (Django Rest Framework).
I implemented AcceptHeaderVersioning and it was working correctly. But then I realized Swagger wasn't showing the endpoints at /docs/ and this message was shown: "No operations defined in spec!".
If I comment DEFAULT_VERSIONING_CLASS line in REST_FRAMEWORK settings, all endpoint are correctly shown in Swagger docs page (/docs/). However, it breaks my versioning: request.version = None.
I tested with AcceptHeaderVersioning, as well as with URLPathVersioning and NamespaceVersioning. Same result for all of them.
I read that AcceptHeaderVersioning was implemented a year ago. Link to the commit here.
But I also read that it was planned to change modify_for_versioning function and it could affect header versioning. Link to the function in plumbing module, here and conversation here. In fact, a lot of changes have been made to the module the last year, check here.
These are my DRF settings:
REST_FRAMEWORK = {
# Auth
'DEFAULT_AUTHENTICATION_CLASSES': [
'rest_framework.authentication.TokenAuthentication',
],
# Swagger/docs
'DEFAULT_SCHEMA_CLASS': 'drf_spectacular.openapi.AutoSchema',
# Pagination
'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
'PAGE_SIZE': 5,
# Testing
'TEST_REQUEST_DEFAULT_FORMAT': 'json',
# Versioning
# https://www.django-rest-framework.org/api-guide/versioning/#configuring-the-versioning-scheme
'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.AcceptHeaderVersioning',
'DEFAULT_VERSION': None,
'ALLOWED_VERSIONS': None,
'VERSION_PARAM': 'version',
}
Question
Any idea of what I'm doing wrong? Any recommendation to make both work together (versioning and swagger)? Any suggestions?
And BTW (this is secondary and not the main question): Is it possible to launch drf-spectacular tests into my own project?
Thanks in advance!
Question 1: Versioning works just fine. This is a common mistake. When SpectacularAPIView is versioned with AcceptHeaderVersioning (via DEFAULT_VERSIONING_CLASS), the request that fetches the schema from SpectacularAPIView likely does not contain the version header, and thus you only get unversioned endpoints (in your case none).
Either explicitly request a versioned schema with /api/schema?version=v2 or set version manually with
path('api/schema/', SpectacularAPIView.as_view(api_version='v2'), name='schema'),
FAQ entry
Where the magic happens and the order in which versions are used.
Question 2: The python wheels do not include the tests. For that you would need to install the source package: https://pypi.org/project/drf-spectacular/#files
I am implementing a Wagtail powered blog within a larger (primarily DRF) driven app. I'm attempting to use drf-yasg for my documentation.
Since installing wagtail, the docs are now throwing
'Request' object has no attribute 'wagtailapi_router'
It looks to be related to the introspection that drf-yasg does, and all I can find about excluding views from drf-yasg is done at the code level. Being an installed module obviously I want to avoid that.
Has anyone got these 2 (3) components playing nicely together?
It's been a very long time since you asked this question, but as I found this while looking for an answer myself, I thought I might share what worked for me.
Note that I'm not using drf-yasg, but rather DRF's own schema generator. They do however have a lot in common.
The problem in my case was that the schema generator URL was defined like this:
path(
"schema/",
get_schema_view(title="My API Schema"),
name="openapi-schema",
),
What I needed to add was a patterns= argument that referenced my API specifically, leaving out the other non-API urls (like Wagtail):
path(
"v3/schema/",
get_schema_view(title="My API Schema", patterns=router.urls),
name="openapi-schema",
),
I hope that helps... someone :-D
I was using "http://sonarserver:9000/api/resources?metrics=ncloc,bugs,vulnerabilities" to get the details of all the projects for sonar 6.0.
After upgrading to 6.4 this url does not work and I am not able to find the alternative for this under the web_api changes page.
Please let me know if anyone knows about an alternative to this.
Error: {"errors":[{"msg":"Unknown url : /api/resources"}]}
Per WebAPI documentation (embedded in your own SonarQube server, linked at the footer): api/resources/index is deprecated since 5.4 (i.e. a super long time ago).
The documentation even provides some guidance:
if you need one component with measures: api/measures/component
That will get you the measures you need for a given project. You can use other APIs to get the list of projects (e.g. api/components/search). See Web API docs for the full listing of possibilities.
We decided to give it a spin and we started fresh project using Angular2. So far so good, but at this point we're facing an issue. At this point, what is the proper approach to i18n for Angular2? We've researched a little and found this:
https://github.com/angular/i18n
However last commit is more than 5 months old... Doesn't look like active development.
Anyone tried using angular-translate or angular-gettext? Or maybe with Angular2 it's better to wrap something JS like i18next? Anyone could share their thoughts? Maybe you faced the same problem?
Plunk was updated to Angular 2 Final: https://plnkr.co/edit/4euRQQ. Things seem to work the same as in RC7.
New i18n section has been added to Angular 2 official docs. Basically, it explains in details what happens in the plunkr above.
XLIFF is the only format for translations, no json support.
A translation source file (xliff, xlf) should be created using ng-xi18n tool:
package.json:
"scripts": {
"i18n": "ng-xi18n",
...
}
and
npm run i18n
See the Merge translation section for details about merging a translation into a component template. It's done using SystemJS Text plug-in.
Another example using Gulp http://www.savethecode.com/angular2-i18n-native-support/
Older staff:
Update based on RC7 and links provided by Herman Fransen:
I've made a minimal Plunkr example: https://plnkr.co/edit/4W3LqZYAJWdHjb4Q5EbM
Comments to plunkr:
bootstrap should provide TRANSLATIONS, TRANSLATIONS_FORMAT, LOCALE_ID with values -> setup translations
translatable items in html-templates should use directive i18n
translations are stored in .xlf file. Ties between languages is done through Id, ties with html by a value of <source> tag in xlf
currently xlf files are not used directly; a .ts file is manually created to wrap the content of xlf in an exportable variable. I guess, this should be working automagically in final release (maybe even now).
This is the first officially documented approach I found.
However, it's still barely usable. I see the following issues in the current implementation:
Language is set at bootstrap, unable to change it in run-time. This should be changed in Final.
Id of a translatable item in xlf is generated SHA. Current way to get this id is a bit messy: you create a new translatable item, use it, copy SHA id from error and paste into your i18n.lang.xlf file.
There is a big documentation pull request concerning i18n
Older staff:
Release notes https://github.com/angular/angular/blob/master/CHANGELOG.md have a record
i18n: merge translations 7a8ef1e
A big chunk of i18n was introduced in Angular 2 RC5
Unfortunately, still no documentation available.
Everyone's eager for the official implementation, but this one worked for my use case:
https://github.com/ocombe/ng2-translate
README is fairly thorough, and if you need something real particular (for me it was code-splitting) the code itself isn't too long or hard to read.
Support for i18n is now official in Angular 2 RC6
Official release blog:
https://angularjs.blogspot.nl/2016/09/angular-2-rc6_1.html
A sample of internationalization with Angular 2 RC6
https://github.com/StephenFluin/i18n-sample
More info how the new concept of i18n works in angular2:
https://lingohub.com/blog/2015/03/angular-2-i18n-update-ng-conf-2015
I found another way to implement this using pipe and service
HTML
<!-- should display 'hola mundo' when translate to Spanish -->
<p>{{ 'hello world' | translate }}</p>
TYPESCRIPT
...
// "this.translate" is our translate service
this.translate.use('es'); // use spanish
...
// should display 'hola mundo' when translated to Spanish
this.translatedText = this.translate.instant('hello world');
...
https://scotch.io/tutorials/simple-language-translation-in-angular-2-part-1
https://scotch.io/tutorials/simple-language-translation-in-angular-2-part-2
There is an official support for i18n in Angular.io here:
https://angular.io/docs/ts/latest/cookbook/i18n.html
But! As mentioned in docs:
You need to build and deploy a separate version of the application for
each supported language!
That makes this feature useless in most cases ...
Unless you will use it without CLI as described here:
https://devblog.dymel.pl/2016/11/03/angular2-and-i18n-translate-your-app/
I am putting together a POC and the official documentation is cumbersome to say the least, so I tried ngx-translate http://www.ngx-translate.com/ and I literally had the hello world working in a few minutes, there are few caveats:
I've read of people complaining about performance, because of the pipes, but reading the github issues, it seems that it is getting resolved
It is only for i18n or Translations it does not deal with i10n or Localization
There are few warning errors with Angular4 but it works anyways
long story short I liked ngx-translate if you have a small app and only need translation
I personally wanted Localization, so I am looking at
https://github.com/robisim74/angular-l10n
. It looks pretty good, but I haven't tested, so I'll let you know later, or you guys can go and we all try
Im working in a beego application with 2 modules, and has a controller with the same name in both modules.
When I use {{urlfor}} in template the generated url is linking with the other module.
Anybody know if its posible select module name in urlfor function? I search in the docs and cant see any reference about. Im currently use beego 1.4.3
Thanks in advance
For anybody with the same issue:
The problem is how I implemented the application folder structure for modules. It seems not be compatible with {{urlfor}}.
The correct answer come from github: https://github.com/astaxie/beego/issues/1100
In the link you can found the correct directory tree