As the documentation says:
The HTTP OPTIONS method requests permitted communication options for a given URL or server.
From this we can conclude that the server must have an HTTP route with the OPTIONS method for absolutely all URLs.
For example, if the server has the following route list:
GET /
GET /users
GET /posts
In this case, the server must also have the following routes:
OPTIONS /
OPTIONS /users
OPTIONS /posts
Am I correct in my understanding that absolutely all routes must have an OPTIONS method?
Should the OpenAPI documentation show all routes with OPTIONS methods?
Related
Currently Redoc includes the host URL in my API endpoint which I do not want it to do.
I tried several ways to hide it and only show the base path and endpoint in Redoc docs, but nothing seems to work.
Current behaviour - http://localhost:8000/v1/abc
Expected behaviour - /v1/abc
I do not want Redoc to add the host.
I tried passing an empty url in the servers attribute in my OpenAPI file, hide-hostname in Redoc options and other various ways like only passing a "/" in the url, but it always adds the security scheme or browser URL if nothing is provided.
Let's say we have a GraphQL NestJS application which acts as a proxy between a client and a REST API server. It's got 3 layers:
Resolver
Services (which kinda have the business logic and stuff)
Something extending HTTPService with added functionalities
We want to add dynamic headers to NestJS outgoing requests to REST API server, which uses axios. The headers are based on:
User: We can read user with the help of User decorator in resolver and pass it down to services, or read it from the GraphQL context as far as I know.
Routes: Different endpoints may require different headers. I think we can specify the types of header that should be added because of a specific rout in the service, but this does not look so scalable... . Or maybe we can store an object of the current paths, that we make requests to. Intercept outgoing requests and use RegExp to determine which path is the request is being sent to (i.e. user/3 would translate to user/:id, which we can add proper headers knowing that).
[
{
path: 'user/:id',
...
},
{
path: 'user/:id/image',
...
}
]
So my question is how can we add headers to outgoing requests from a NestJS application to some endpoints based on the path(url of the axios request) and the current user. Is matching a url with some RegExps while intercepting an outgoing request expensive?
Had the same problem and solve it by using Injection Scopes in Nest GraphQL
https://docs.nestjs.com/fundamentals/injection-scopes#request-provider
However, there's a caveat in terms of performance.
Is it possible for requests to the API-Gateway to pass the referrer URL to Lambda? For example, I'd love to let my lambda functions know if a request comes from the domain "good.com" vs. "bad.com".
I'm familiar with the list of supported $context Variables and I know a referrer url is not in there. I'm wondering if there is another way. If it is possible, what steps do I need to take?
Here's how to do it.
As it turns out, the mapping template allows you to map HTTP headers, not just the list of supported variables in the documentation.
The HTTP header that contains the referrer domain is called "Origin". The header that contains the referer page URL is called "Referer".
So, for example, you can put this in your mapping template and it will grab the associated header information:
{
"origin" : "$input.params('origin')",
"referer" : "$input.params('referer')"
}
Origin grabs example.com. Referer grabs example.com/pagename
It's an HTTP header, so if you are mapping HTTP headers in the template it will be passed to the Lambda function. Look at this answer for an example of how to map HTTP headers in the request template.
I have a website power by a tomcat server. My application tap on a tripleStore that i would like to make public trough a sparql endpoint at www.mywebsiteaddress/sparql.
What configuration do i need on my webserver to do that ?
I use Jena Fuseki on the background which is running on the Port 3030 and my webserver is on the port 80.
My idea is that, when the webserver get a request on the port 80 about ..../sparql it redirect to fuseki sprql endPoint
This is more of a webservice / access control problem than anything SPARQL related. However, since SPARQL endpoints are supposed to be created as per the SPARQL spec, i think this a valid question, as I'm sure people will encounter it again in the future.
So, to answer your question, "public" usually means that certain headers are set in order to allow a request to hit the endpoint when it is not coming from the same domain. From there, you can specifically allow certain types of interactions with the endpoint. If you wanted to kinda just allow everything, you could set the following headers:
'Access-Control-Allow-Origin: *'
"Access-Control-Allow-Credentials: true"
'Access-Control-Allow-Headers: X-Requested-With'
'Access-Control-Allow-Headers: Content-Type'
'Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE //http://stackoverflow.com/a/7605119/578667
'Access-Control-Max-Age: 86400'
Depending on how you built the endpoint, it'll either have some settings somewhere where you can adjust the headers, or, you'll have find the headers settings for the application framework itself if you're using one. But, in general, the above headers would make it "public"
I'm using fiddler to test a Web API service I'm writing.
I know I can pass parameters to a RESTful web service in the querystring with a request like -
www.example.com/api/Book?Id=123&category=fiction.
Are there other ways of passing the parameters to the service, while still using a GET.
There are many parts of the HTTP request which you can use to pass parameters, namely the URI, headers and body. GET requests don't have bodies (some frameworks actually allow that, but they're not common so for all purposes, let's just assume that they can't), so you're limited to the headers and the URI.
In the URI you can pass parameters in different places:
Query string (as you're already doing)
Ex.: www.example.com/api/Book?Id=123&category=fiction
Request path
Many frameworks will allow you to get parameters to your actions from paths in the request URI. With ASP.NET Web API you'd typically do that using routing
Ex.: www.example.com/api/Book/fiction/123
In the fragment, or the part of the URI after the # character. See the URI RFC, section 3.5.
Ex.: www.example.com/api/Book?Id=123&category=fiction#somethingElse
You can also pass paramters in the HTTP request headers. One parameter which is honored by the ASP.NET Web API is the Accept header, which is used when doing content negotiation. You can also expect custom parameters from those headers, and read them in your actions (or even have value providers which will read them and map them to the parameters in the methods themselves).