Mockman does not accept a valid body request unless the content-type of the request is application/json or multipart/form-data.

At the very least, it should also accept request's body which content-type is application/x-www-form-urlencoded. Check the screenshot below:

When you set a header on the Request tab with something like X-Custom-Token and the client requests with a header of either X-Custom-Token or x-custom-token, Mockman will not recognize any of those. Check the postman screenshot below.
Capitalized first letter header

Lower-cased header

As according to the official specs rfc7231

3.2.  Header Fields
   Each header field consists of a case-insensitive field name followed
   by a colon (":"), optional leading whitespace, the field value, and
   optional trailing whitespace.

Therefor, Mockman should accept valid header fields regardless of its letter-case.

Note:
Mockman accepts case-insensitive headers only if the header on the Request is set to all lower-case.

Hi,

Is it possible that create a folder which store all fake api in project, and then it can be git track and share to team use?

THanks :)

Mockman does not allow setting query parameters on the path section. If you add a query parameter, the path does not work.

An example:
Side to side screenshot of Mockman as the mock server and Postman as the client.

Suggestion:

• Allow user to direct input the query parameters on the path field, and automatically add it on the request's Param section.
• Also it would be nice to allow user to set a static value for those params and only accept requests if the parameters are the same value.

The prebuilt crashes on Windows because sqlite3 is missing.

Question

in our interface definition specification, there can be dynamic parameters in the url of the get request method. Excuse me, in such a scenario, how should I use Mockman to simulat data?

For Example

Method: GET
URL: /files/download/{resourceCode}/{other dynamic params}

Swagger

the resourceCode in the url is a variable, which is generated according to the front-end user's choice

Bug

• The response body does not allow text/string responses. It only allows if it is double quoted. So when you put "ok" on the response, the respond will be the same with quotes. It should basically allow anything with or without quotes.

Suggestion

• Currently the response's default content-type is set to be application/json, I know most apis responds with this type, but is not always the case. Its ok to have this as default, but i suggest that you automatically add/include it on the headers section, so user knows that it is using application/json content-type.
• Same with the content-type, if you want to set the Access-Control-Allow-Origin to * then add/include it on the headers section so users knows that it is using it.
• Allow setting a cookie with specific path, domain, expiry and the option httponly, because currently, the cookies are always set to path=/ domain as localhost http false and empty expiry.
• Do not allow multiple routes with the same path and same method, as this is redundant and your app will always use the first one declared.
• Add HEAD method.

Standards

• According to HTTP Methods GET HEAD OPTIONS do not accept body parameters. So do not allow setting of body parameters for those routes.

If you accept PRs I'd be happy to look into some of them. Cheers!

Edit:

• Would also be nice to remove the X-Powered-By: Express on the response headers

Export Feature:

• Export Server and all Routes

• Export Individual Routes

Import Feature:

• Import Server and all routes

• Import Individual Routes

This would be a great feature set for collaboration between teams

Dynamic responses
I'd like to request additional feature to be able to mock a server and respond dynamically based on parameters.

Excample scenario of this request:

• I create a mock server running on localhost:3000/api/getinfo with a params of user
• Then i could add a simple json record where the app could get the info from.
• Then on response tab, i can put something like { "success": true, "data": $user }
• The mock server will then get the data part on the given json based on the given params.

Custom error response

• The current setup is when a params is given and it is missing from the request, it will respond with {"errors":[{"key":"user","details":"required params."}]}
• It would nice if the user is able to customize this respond on every route.

Advance Logging

• It would be nice to have something like an advance tab where user can view the actual request that was received. Something similar to this image
  

Thanks!

Building from source on windows platform (Windows 10 x64), npm run build return this error:
Expected linebreaks to be 'LF' but found 'CRLF'

Adding the following rules to .eslintrc file fix the issue:

'rules': {
	"linebreak-style": 0,
	"eslint linebreak-style": [0,"error","windows"],
...

It would be great to have option to clear Logger view ether through menu or using a button on Logger view.