Add API documentation to website using Swagger document - json

I have a basic webpage built, and a Swagger document JSON file of my API. I am unsure of how to actually add the data from the document to the website so that it can be browsed.
I want to build hosted documentation for the API.
This is the example given by Swagger: http://petstore.swagger.wordnik.com/#!/pet/addPet
Do I just download Swagger UI and use it in conjunction with the JSON file.
But I am unsure on to achieve this. Any advice on how to go about creating something like this would be very helpful.

Swagger-ui is basically a set of static files you can host on your server to display your API.
Unless you may any major changes, you just need to copy the contents of the /dist folder to your server and host it as part of your application (or static website, doesn't matter).
The SwaggerUi object can be customized to your needs, including the URL of the spec you're hosting.
Keep in mind that if you don't host the ui and spec on the same server, (that is, same host and same port), you need to enable CORS.

Related

Is it possible to create an HTML link to a specific API within a JSON Swagger file?

I have swagger files with URLs like https://gitlab.com//blah/blah/Orders_Swagger.json. I'm building some documentation that links to these files; that works fine. Gitlab renders the page with nice formatting. But some swagger files have dozens of APIs and sometimes I want to reference a specific, critical API, not just send the user to the top of the page.
Swagger UI supports a "deepLinking=true" configuration parameter. It is set to false by support. Gitlab embeds Swagger UI, but does not provide a way to set this parameter, so it is off at the server level.
However, you can enable it by passing a parameter in the URL: &deepLinking=1
Thus, a full, API-specific URL will look like this:
https://gitlab.com/company/blah/blah/Swagger.json?deepLinking=1#/section/targetApiName

Can node-red html be edite elsewhere?

I'm developing a node-red application right now that uses a html response. The html uses google maps, visual indicators and websockets. It is very hard to debug this system through node-red's little html editor. Is there a way to edit the html file through any normal editor (e.g. vs code) and then deploy the application again to see the effect ?
One solution that came to my mind was to read from an external file using the file node and return it as html, put I don't know if that works. Is there a better way ?
You can create and edit static resources (html/css files etc) however you'd like and then serve them from Node-RED.
You have two options for serving static content:
create corresponding HTTP In -> File In -> HTTP Response flows for each file you want to serve
or use the httpStatic property in your settings.js file to identify a directory whose content should be automatically served by the runtime.

How to use local JSON assets to simulate API in Scala.js

I'm new to Scala and Scala.js and I want to experiment with handling JSON data. I'd like to simulate a server response by returning the content of a JSON file local to my Scala.js project, parse it and work with the data. What would be the best way to do so? Where should I place these files in my project tree, and how would I get their content?
Say that I have a file called myJSON.json containing something like
[
{
"ress": "AR",
"lastDate": "2017-10-27 09:19:18"
},
{
"ress": "JIM",
"lastDate": "2017-10-27 06:57:15"
},
{
"ress": "JOE",
"lastDate": "2017-09-29 11:57:39"
}
]
Can I place this file somewhere in my project so that I can read this file and then parse its content to use it somehow (could be displayed in the browser, logged to the console, etc...)? I guess I could use a tool such as scala-js or something similar for parsing, but accessing the file content in the first place is what I try to figure out.
Note that I'm using scala-js.
Thanks in advance!
Like others said above, Javascript that runs in the browser in general can't access the local filesystem. There are some exceptions:
The File API lets you access files that the user has selected in the UI using <input type="file" /> or drag-and-dropped into the browser window.
The Filesystem API lets you access files the way you seem to want, but it is non-standard and is not supported in most browsers. It also seems that Scala.js has no typings for it, but I'm not sure.
scala-js-dom has typings for the File API that you can use – search for File and FileList types in its source. Its API mirrors the Javascript API, so you will need to look for how exactly to do this in JS. Then translating it into Scala.js will be easy (or at least a different question).
If the File API does not work for your use case, another option is to use something like json-server to easily serve your JSON files on localhost via HTTP.

Where the Swagger pretty HTML code?

There are only ugly HTML pages as download (HTML, HTML2 and dynamic all ugly), but the site, eg. edited https://app.swaggerhub.com/apis/{user}/{project}/{version}
(and many others!) offers pretty HTML interface... How to download this pretty HTML?
Complete and autonomous HTML code (file or zip of files).
I have a good and valid swagger.yaml or swagger.json file of my API, so another solution is to run a open sourse (plug and play!) tool with my API-description file.
The pretty:
The ugly:
The "pretty interface" on your screenshot is Swagger UI. It's free and open-source. There's a demo at http://petstore.swagger.io, where you can load your own YAML/JSON files from an URL and see how they would be rendered.
To use Swagger UI locally:
Go to https://github.com/swagger-api/swagger-ui and download the repository as ZIP:
Edit the dist\index.html file and change the line
url: "http://petstore.swagger.io/v2/swagger.json",
to the URL of your Swagger .json or .yaml file, e.g.
url: "http://api.mysite.com/swagger.json",
(Optional) Add/change other configuration parameters in the SwaggerUIBundle initialization code in dist\index.html.
Open the dist\index.html file in your browser to preview your API docs.
Note: If the spec does not load or "try it out" does not work, you probably need to enable CORS on the your server. See https://github.com/swagger-api/swagger-ui/blob/master/docs/usage/cors.md and https://enable-cors.org.
Upload the files from the dist folder somewhere to your server - and now you have pretty API docs too!
Alternatively, SwaggerHub (which you mentioned) provides cloud hosting for Swagger specs among other things, and has Swagger UI integrated. You can import your Swagger .json/.yaml files there and have your API docs hosted on SwaggerHub. A free plan is available.
Thanks to #tleyden at swagger-ui/issues for good clues!
Use the index and assets folder of this project, https://github.com/okfn-brasil/swagger-ui-html

Using filepath as a hyperlink in HTML

I Wonder whether I can use pdf Source[as hyperlink] as a file path in system related to script's running directory.
part of code is.
pdf
I am generating this HTML using CGI Scripting in C. and my pdfs are located in ../pdfs/sample.pdf related to my running directory of script. And by pdf source means I want to show the pdf sample.pdf upon clicking pdf as in above sample code.
A browser does not care or know how a resource is generated. You can generate it with C via CGI, you can have the server just hand over a static file. There is no difference as far as the browser is concerned, it made an HTTP request and received an HTTP response.
The rules for resolving a relative URI in an HTML document are the same. The browser compares it to the base URI (which is either specified in <base> or is the URI of the document containing the link).
If that resolves to a URI that the server will serve a PDF up for, then it will work.
Since URIs don't always map directly onto file systems, it isn't possible to say if this will work in your situation (as your question only talks about file systems). If this was on one of the servers that I have CGI programmes executing on then it wouldn't work — since I keep them in a cgi-bin that isn't a subdirectory of the webroot, so the pdfs wouldn't be accessible over HTTP at all. Your server may be configured differently.