Gathering detailed insights and metrics for rest-server-dummy
Gathering detailed insights and metrics for rest-server-dummy
Gathering detailed insights and metrics for rest-server-dummy
Gathering detailed insights and metrics for rest-server-dummy
restful-dummy-server
This can be used to mock restful api responses.
@wll8/json-server
Get a full fake REST API with zero coding in less than 30 seconds
rest-dummy
Restful dummy services, dummy services using nodejs server.
quick-rest-server
Generate simple REST API in a fastest way.
npm install rest-server-dummy
Typescript
Module System
Node Version
NPM Version
JavaScript (100%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
4 Stars
15 Commits
1 Watchers
2 Branches
1 Contributors
Updated on Nov 09, 2022
Latest Version
1.0.14
Package Id
rest-server-dummy@1.0.14
Size
4.59 kB
NPM Version
2.15.1
Node Version
4.4.4
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
6
If you are developing a REST-Client than you definitely need this mock server
1npm install rest-server-dummy -g
When you are dealing with remote REST API's as a developer of a client Application, than you should have something on your local machine that mocks the API.
rest-server-dummy is the tool you want to debug GET, POST PUT and DELETE calls in the easiest way. Here is the simple elegance of stupidity that just works. It will save you from a lot of trouble while you developing on your software.
After you have installed the Software, you should start the server:
1node rest-server-dummy
The default server settings are:
PORT | 8080 |
DIRECTORY | ./ |
Now you can work with the server in your application with the url
http://localhost:8080/some/great/file.json
in 1.0.3 you do not have to provide .json to the resouce
http://localhost:8080/some/great/file
will generate a file in the /some/great directory that called file.json
Everytime you post a document to the server it will create a file in the DIRECTORY. If you are working with the default setting, and post /some/great/file.json, than a directory called "some" will be created in your current work directory. Inside that directory an other one named "great" is created and inside this a file named "file.json" stores the content from your POST Request.
To explain further examples, we asume at this point that you post a document that looks like this:
1{ 2 "name": "james" 3}
It is not very complex but you will know better what fits your needs and can build your own document.
A PUT will alter a document. For example we a document to the same address: some/great/file.json
1{ 2 "gender": "male" 3}
Than the result in the file will be merged to:
1{ 2 "name": "james", 3 "gender": "male" 4}
You can fetch posted documents, or you can copy mock .json files to the directory structure and fetch them with a GET Request.
A GET on some/great/file.json will return the same document:
1{ 2 "name": "james", 3 "gender": "male" 4}
If you request a DELETE method, the file, and the directories will be removed. A GET after a DELETE should produce a 404.
The directories will be removed when there is no other file only. Even a .response file will halt the removing process!
While deleting a resource no request file is produced.
Every call will produce a extra file with the suffix .request If you are GET/POST/PUT a resourcece (for example: some/great/file.json), a file named some/great/file.request will be written. In this file your request headers are stored.
1{ 2 "host": "localhost:8080", 3 "accept": "*/*", 4 "content-type": "application/x-www-form-urlencoded", 5 "connection": "keep-alive", 6 "user-agent": "YourApp/0.1", 7 "accept-language": "en-us", 8 "accept-encoding": "gzip, deflate", 9 "content-length": "7" 10}
This is very handy when you debugging your client. All headers are stored right beside the content.
Maybe you do not want the results in the working directory? No Problem, just start up the server with a DIRECTORY option and all files are stored there:
1DIRECTORY=/tmp node rest-server-dummy
Debugging clients is hard. But not as hard as Haddekuche!
To fetch the document with additional headers, you can write a .response file with the same baseman as your resource and store some headers there. In our example a file named: some/great/file.response will be merged to the headers that are returned to your client.
1{ 2 "foo": "bar" 3}
That response file will produce a header like:
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Server: rest-server-dummy
Access-Control-Expose-Headers: Api-Version, Request-Id, Response-Time
Api-Version: 1.0.0
Content-MD5: TGOyctqnSLSYozRZIPJyyQ==
Access-Control-Allow-Headers: Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, Api-Version, Response-Time
Response-Time: 15
Date: Fri, 27 Feb 2015 16:31:56 GMT
Content-Length: 126
Connection: Keep-Alive
Request-Id: 25570e50-be9e-11e4-b5c2-235a2c2e6d6c
foo: bar
Ask us on Twitter @ausderTechnik
if you like this tool, spend a Satoshi to this address:
1DtvkCh28zqarTEUHtxs7gWtutsv2Cnf9d
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
no SAST tool detected
Details
Reason
Found 0/15 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
license file not detected
Details
Reason
branch protection not enabled on development/release branches
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More