Comments (9)
Is there any progress on this topic? I would love to use this enhancement :)
from datasource-rest.
Is there any update on this? I also need to make HEAD method request using RESTDataSource but there is no support for that.
from datasource-rest.
@abernix Any update?
from datasource-rest.
it’s not the best solution but if you need a fast solution just use fetch and do a HEAD request
from datasource-rest.
@abernix Any update on this? We recently ran into this issue.
from datasource-rest.
I don't have the precise answer as to the exact "why", but I could certainly believe that the omission of HEAD
from the original implementation was because it wasn't fully realized that there was much in the way of data to be retrieved from such an endpoint (that doesn't return a body).
That said, data obviously comes in various forms and it's entirely possible to return certain valuable data as header values, so I think the need resonates with me too.
Thanks for opening the pull request, @Phoenix1405.
from datasource-rest.
I just passed the header into my returned data as a symbol
from datasource-rest.
I believe HEAD
requests can also compute data, just not return a body. That can be cached with RESTDataSource
, so the addition of the HEAD
method is quite practical.
from datasource-rest.
Ok, having familiarized myself with HEAD
semantics I feel prepared to discuss this and propose a couple options.
HEAD
bodies in responses must be ignored, meaning all of their useful data exists in the response headers. They ought to be treated as aGET
request with no response body.RESTDataSource
in its current form doesn't expose theresponse
object (just the parsedbody
) in its return value offetch
or the helper "http method" methods.
Based on this information, I'm going to assume people want access to the response headers when the make a HEAD
request (else it's just an empty string). AFAICT, @Phoenix1405's PR mentioned above did not address this. I'm really not sure how useful this API addition can be otherwise, though.
I propose 2 possible options (with the option of 1, then later 2):
- Add a
head
method which breaks convention from the other convenience methods, i.e. it does not return a parsedbody
and instead returns either the wholeresponse
object or just itsheaders
. This will result in some additional internal complexity aroundHEAD
being special (i.e. thefetch
method will have 2 different return types and have to look forHEAD
, etc.). It also creates an inconsistency in the API (making it unique among the other convenience methods). - In a breaking change to the API, start returning additional data in the convenience methods (either the whole
response
object alongside a parsedbody
or something similar, but at a bare minimum theheaders
as well).
I'd be interested in hearing input on these options from anyone on this thread. I'm leaning towards 2 myself since it offers a more robust and consistent API.
from datasource-rest.
Related Issues (20)
- Next release of package @apollo/datasource-rest HOT 2
- Type signature for params is too narrow HOT 4
- RESTDataSource’s willSendRequest parameter changes HOT 2
- Get/Set HTTP Status? HOT 1
- willSendRequest this.context does not exist on xxxxDataSource HOT 1
- `didReceiveResponse` hook no longer available, blocking Apollo v4 upgrade HOT 6
- Errors stop getting sent to client if the override of fetch includes a catch callback HOT 2
- Configuring external caching in Apollo v4 HOT 3
- Question related to changes in request parameters HOT 2
- RESTDataSource implementation issue with `willSendRequest` & `@apollo/utils.withrequired` is a devDependency HOT 4
- Apollo Datasource adds content-type: header when Content-Type (case sensitive) header is set HOT 3
- RESTDataSource no longer have access to all datasources through context HOT 2
- Document `contextValue` recipe for circular references in context object
- Posting FormData as body (for file uploads) not possible anymore HOT 7
- Forward all cache options to key value cache HOT 6
- Unable to connect to Localhost server HOT 1
- @apollo/datasource-rest willSendRequest param type missing `agent` HOT 7
- [apollo-datasource-rest] Handling 404 errors HOT 2
- Feature request - be able to tell if API was resolved by memory, cache, or source HOT 3
- RESTDataSource - body based cacheKeyFor POST request HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from datasource-rest.