APIs Sandbox

https://www.openapis.org/ is building on the Swagger spec to create an open, general spec for REST APIs.
Meanwhile, use Express or Restify.

REST is implemented in the Express Node.js module. Express provides a clean, fast and small implementation of REST. The two key REST APIs are POST and GET. Most web applications implementing REST need just these two.

Example:

app.post('/links3/:question/:frame/:impression/ :visitor/:token/:url_text', function (req, res, next) {})
app.get('/links3/:question/:frame/:impression/ :visitor/:token/:url_text', function (req, res, next) {})

Browsers send these APIs to a running Node.js app and, in return, receive populated HTML in response. The HTML is delivered and populated by Node via HTML templates stored on the server and by data from a database in use by the Node app, usually Mongodb. If a form is being submitted from the browser, then a POST API is required. This is because form data is hidden in the HTTP packets exchanged with the the running Node app as opposed to passing data in the actual arguments in the API, which is visible to the user and (presumably) anyone else. Secure HTTP (HTTPS) encrypts packet data, so form data is secure with POST calls. Data in the returned HTML is also encrypted. That's really why you must have POST in addition to GET.

Note that the signature of the two APIs is identical. This enables the user to send a link to someone else so they can view a response without having to securely submit any data. Express distinguishes between POST and GET APIs and if it receives an API that is sent using GET and there is no corresponding GET API in the app, then you get this message:

Cannot GET /links3/6939e6efea23336df07a0eeb/30/0/6/0/Under-Trump-20-has-America-become-a-far-right-wing-authoritarian-state

If the user is going to be sharing links with others, there must be a GET API implementation for the API or the person who receives the link will get that error when trying to use it. You can't share POST links.

Each API should have a unique name and signature, with a few exceptions:

GET and POST APIs in the public space. You need a corresponding API with the same signature for any POST API in the public space. That way the app can handle a cut and paste of a POST API's signature if the visitor shares it. If you don't have the corresponding GET, the POST version will give an error.

Same API, diffferent signatures. The API with the corresponding signature will get called. This makes a cleaner API in terms of how visitors and users "see" the calls. You don't need API names like https://write and https://write2, etc. One "write" API can handle multiple cases. The same API with different signatures is also useful when you need to add or change a signature. The old API can still "live" out there for backward compatibility with existing references that still live in databases and elsewhere on the Internet.

Shared APIs between public and private. Often a user will try to cut and paste an API from a private space into an e-mail for sharing. Of course that won't work when the recipient gets it. You need to make the same API and signature available in both the public and private spaces to handle these cases or the recipient of the link will get an error.