How can I configure nghttpd to response differently based on the request? - server

When I start a server with
nghttpd --no-tls -v 8444
And in another terminal I send a request
nghttp -v -y http://127.0.0.1:8444
I see that the server saw my request and responded with 404. Is it possible to configure to respond differently based on the request? (I 'd like to implement some basic logic, different return codes based on request method, path) Can you show me an example for that?
Lets say for GET request with /dog path return 200, and to post request return 404

I don't think this is possible. Nghttpd is a simple webserver to demonstrate the nghttp library and also useful for debugging HTTP/2, but it is not intended as a fully featured web server.
As an aside, I would also question whether a POST should return 404 to a valid path. 404 is "Not Found" which is not right - the resource is found. Most web servers would return the same as a GET request for such a request (as does nghttpd).

Related

How to mock HTTP Error response with Charles?

Is it possible to intercept the request going through Charles and immediately return 500 error code without sending this request to the server?
Can't find any information on this. All resources suggest to wait for the response and then change HTTP response code to 500.
I assume you have already tried adding a rewrite rule to make the request to be returned with the 500 status. Have you tried combining this with a map local, to an empty file on your disk, for instance? It may work.
If this doesn't work too, I think I would do a Map Remote to another path on my localhost (for instance: http://localhost:8081/exected-response-500) and make that URL to return the 500 status error (in my case I would use a basic Spring Boot app to achieve this).

What status code to use when a parameter is missing in the query string?

I have an endpoint that requires a parameter passed via the query string (is a GET verb).
What is the appropriated status code to give when this parameter is missing from the request? 400 is the one? or should I respond with a 404?
[GET /search?q=ok] => 200 OK
[GET /search] => 400 Bad Request? or 404 Not Found? Or 422 Unprocessable Entity? Others?
TLDR It's an HTTP 400 - Bad Request.
It's a 400 because the user did not send the Required input field.
why not 422 - because this case fits to 400. Keeping your consumers in mind, you shouldn't go to non-popular response codes if you don't really need to.
Cases for HTTP 404:
Url which the client requested is not existing in your server (usually this will be handled by your server. Application developer usually doesn't have to do anything unless you want a nice looking 404 page or for SEO reasons).
If it was a path parameter and client was looking for an entity with an id (for Example (/students/{id} and your application couldn't find such entity, you may respond with an HTTP 404.
Let's say, user send the query parameter and you did not find any items matching the query param, make no mistake, it's still an HTTP 200 with body as an empty array or so (not a 404 unlike mentioned in the previous case). Example: /customers?lastname=unobtanium
It should be 400 - Bad Request.
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
404 - Not Found
The HTTP 404 Not Found Error means that the webpage you were trying to
reach could not be found on the server. It is a Client-side Error
which means that either the page has been removed or moved and the URL
was not changed accordingly, or that you typed in the URL incorrectly.
Its means server is not able to find the URI you specified. but in your case URI is valid but parameters are missing so 400 is right way to do it.
What is the appropriated status code to give when this parameter is missing from the request? 400 is the one? or should I respond with a 404?
I would argue that 404 is appropriate
The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not
willing to disclose that one exists.
The fact that your routing implementation happens to send /search and /search?q=ok to the same handler does not mean that they are the same resource. /search identifies a resource, there's no current representation available for it, so you send a response back to the consumer explaining the problem, and put 404 in the meta data.
The big hint in the spec is this one:
A 404 response is cacheable by default
That lets us inform the client (and any intermediary components) know that this response can be reused.
It's a useful property, and it doesn't apply (out of the box) to 400 Bad Request
Heuristic: your web api should act like a document store. If you ask a document store to give you a document, but you spell the key wrong, what do you get? Some flavor of KeyNotFound exception. Same thing you would get if you asked a web server for a document in your home directory, but your spelled the file name incorrectly.
The semantics of the response indicate the right status code to use, not the implementation details.

How can red be used to connect to REST apis?

I found that there is a red command to download contents of a web page:
read https://trello.com/c/8p75OiSE/26-test-card.json
However, I have two problems (at least on Linux Mint):
Trello's response differs for this request than it does for simply visiting this URL in a web browser (try it! it works fine in a browser).
If I did need to add authorization headers (shouldn't for this public card), I don't see a way to do that.
It is even worse in Tio.run, but I'm pretty sure that is not a problem with the language itself but with Tio.run.
WRITE, and more specifically WRITE/INFO should give you enough leverage to engage most APIs.
The most basic usage of WRITE returns the body of the HTTP response:
probe write http://some.resource/api/method "Some Data"
You can get the header of the response by adding /INFO:
probe write/info http://some.resource/api/method "Some Data"
And you can send different HTTP methods and headers using a BLOCK! as your WRITE argument:
probe write/info http://some.resource/api/method [
put [Content-Type: "application/json"] {["Some Data"]}
]

How to use postman API client with openchain API server

I have just installed openchain (http://openchain.org)
I can check it on http://nossl.wallet.openchain.org/ but I would like to check API using Postman Rest client tool on my PC.
I'm using postman rest client and I have tried URI many times but response is empty : https://docs.openchain.org/en/latest/api/method-calls.html
Please give some advises, thanks in advance !
You should want it to look like something like this picture. Check your headers also, when I use the URL https://www.openchain.org/endpoint/query/recordversion?key=FFFF I get nothing and then when I check the headers I see there is a 404 status which means I was able to communicate with the server but it couldn't find my key. Which makes sense since I am just passing a random key. So see if you are getting a 404 error in your headers and if so then make sure your key is correct.

Why am I getting request method GET not supported?

I am using PostMan as a REST client to test this API method Cisco ACL Analysis API. specifically POST /acl/trace or getAClTracksStd (first go to Policy Analysis)
Here is my PostMan HTTP test call
Does anyone who is familiar with PostMan understand why I am getting this "Request method 'GET' is not supported" error from the server? I am making a POST HTTP request, not GET.(Selected from Drop down menu) It make more sense for me to get a input invalid parameter error or something.
Just to show that the endpoint url works, heres a HTTP test request that works
(same link, host->host API -> GET /host/{startIndex}/{recordsToReturn}
There's two issues that I'm seeing with your REST call. First, the error you're seeing is because the call needs to be preceded by "https://". Second, remove the interface IDs parameter and values. You should get a response with data after making these changes.
Your json looks erronuous (comma after the destIp) - and the server probably always responds with a default confusing error message in this case. (Postman is very well tested and it sends POST).