I need an app that takes REST API spec and builds HTML forms for client input. Is there something like that out there? I'm not sure if I'm searching the right terms.
Related
I've been search for a couple of months now for nice swagger to HTML converter and I can't seem to find anything that will generate something that looks like the Strava API reference (https://strava.github.io/api/v3/routes/#list) or the Paypal API reference (https://developer.paypal.com/docs/api/payments.billing-plans#plan_create).
They are not the only one with this template so I'm guessing it's an HTML generator that I just couldn't find with my google search skills. Anybody knows how to generate doc looking like this without coding it yourself?
Given that you already have the Swagger/OpenAPI spec, you can use Swagger Codegen to generate documentation.
Go to https://editor.swagger.io
Import your Swagger spec under "File" in the top menu
Under "Generate Client" in the top menu, select Html2 (preferred), HTML or dynamic HTML.
(https://editor.swagger.io leverages https://generator.swagger.io to generate code and https://generater.swagger.io is powered by swagger-codegen)
I am looking for any ReactJS based lib that utilizes json as input and renders the HTML accordingly. Bonus if it can do automatic validation for the end user's input. Example it takes a json input having an array and renders it as HTML select control.
Also the lib should have the possibility to be used without nodejs, I mean in a simple web application like for example Asp.Net MVC based web app. Much better if it has examples and good documentation.
I have a form getting parameters (method=GET, so the parameters are in the query string), and I have an Object with an embedded Google map. I want to make the embedded map dynamic, so that it will reflect the parameters (especially ll parameter for position). There are related questions with answers on how to do it with php and javascript, but is there any way to do it without scripting?
Is it possible in XHTML 1.0 Strict?
Plus, what should be the "target" syntax in the form? Neither "" nor the URL of current page does work, and different page just sends me away, which is not what I want.
When the form and the object(iframe with the map?) are located on the same page you may send the form directly to the iframe, in that case it would be possible to have a dynamic map without any scripting.
But however, when you use POST the parameters are not within the QUERY_STRING.
I know there is a list of similar questions but all handle pages without user interaction (static even though some js may be there).
Let's say we've a page the user can interact (e.g. svg than changes, or html tables with drilldown - content changes). Those interactions will change the page. Same happens in stackoverflow when entering the question...
The idea is adding a button, "convert to pdf" taking the state of the html and sending to the user back a pdf version (we've a Java server).
Using the print of the browser is not the answer I'm looking for :-).
Is this a stick in the moon ?
You would have to store the parameters that generate the HTML view (i.e. what the user clicks on, what selections they make, etc). If you can have a list of parameters that generate the HTML view, you can have a method which accepts the list of parameters (JSON post?), generates the HTML view and passes it to your PDF generating routine. I'm not too familiar with Java libraries for this purpose, but PHP has TCPDF can take html output to basically generate a PDF for you. Certainly, there are Java libraries which will allow you to do the same thing, or you can use the parameters to get a list of rows/arrays which can be iterated over and output using the PDF library of your choice.
Both iTextPDF and Aspose.PDF would allow you to do that (I've seen them used in two different projects), but there is no magic and you will have to do some work.
The steps are roughly:
Get (as a string) the part of the document which you want to print with jQuery or innerHTML
Call a service on the server side to convert this to PDF
[Serverside] Use a whitlist - based tool to clean up the hmtl (unless you want to be hacked). JSoup is great for that.
[Serverside] Use IText or Aspose API to create the PDF from the HTML (this is not trivial, you will have to read the doc)
Download the document
I'd also recommend DocRaptor, an HTML to PDF API built by my company, Expected Behavior.
DocRaptor uses Prince XML to generate PDFs, and thus produces higher quality results than similar products.
Adding PDF generation to your own web application using our service is as simple as making an HTTP POST request to our server.
Here's a link to DocRaptor's home page:
DocRaptor
And a link to our API documentation:
DocRaptor API documentation
Is there any microformat/standard for implementing search form on the site?
(access keys, naming etc.)
Any good practices?
The only things I can think of are that searches should be GET requests, and that you may want to implement a RESTful API that allows developers to query JSON and XML results in addition to HTML
If you are trying to implement a plugin for browsers like IE and Firefox to allow for search/autocomplete in the search box of the browser, check out this: https://developer.mozilla.org/en/creating_opensearch_plugins_for_firefox
Here are some conventions I follow. Forgive me if these are not exactly on topic with microformats, or "technically not" in the way I describe the various parts to my answer.
I have found validation in these few standards I've copied from others:
HTML form ID = "search"
Action URL for the form is //root-of-site/search/
Search Results URL construct:
//root-of-site/search?q=queryClause1+Clause2&AnotherParamName=foo
[personally that structure bugs me a little because search-forward-slash appears to be a directory, and the search-question-mark looks like a page taking a query string, and IMO a page should have a suffix. I've been tempted to use search.cgi or search.app, but I see the big guys using /search?q= and so it is]
ID of search query is "q" (this is nearly universal in adoption)