Fetch is a great api in javascript, because the browsers had different objects to create an ajax request.
The naming could be better. Fetch implies to get something. Most of the times the statuscode is something that gets processed, but not all requests have a payload.
It is good it is an abstraction of guzzle. The problem, in my opinion, is that the functions make guzzle less powerful.
The client is created on each request with fetch. Most of the time when a specific api endpoint is requested, a pre configured client can be used if guzzle is used.
Guzzle has http verb methods. This is easier to read and understand what is going on.
Guzzle is already an abstraction on top of the php methods. Creating an abstraction of an abstraction feels like a cog too many in the machine. This is also the reason I don't use the Laravel http client and other guzzle wrappers.
That's a very good point. The function does have the option to use an already existing instance of Guzzle but your point is valid. Need to look into this. Thanks for pointing this out!
I only glanced at the code on github, so I missed the option key client. So you covered that argument.
I think you don't need to change too much, the library is a good package as a helper in the RAD system of thinking. That is also why Laravel has the guzzle wrapper, and many other helper methods.
And when the time comes that is has been decided that the application needs a more futureproof base, the helpers can be unwrapped and the dependencies can be evaluated.
The only other standalone I could find is github.com/WordPress/Requests. So i think space for well crafted request libraries is not saturated.
It will not be my go to library, but I applaud your effort and I hope to see more of your code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Fetch is a great api in javascript, because the browsers had different objects to create an ajax request.
The naming could be better. Fetch implies to get something. Most of the times the statuscode is something that gets processed, but not all requests have a payload.
It is good it is an abstraction of guzzle. The problem, in my opinion, is that the functions make guzzle less powerful.
The client is created on each request with fetch. Most of the time when a specific api endpoint is requested, a pre configured client can be used if guzzle is used.
Guzzle has http verb methods. This is easier to read and understand what is going on.
Guzzle is already an abstraction on top of the php methods. Creating an abstraction of an abstraction feels like a cog too many in the machine. This is also the reason I don't use the Laravel http client and other guzzle wrappers.
That's a very good point. The function does have the option to use an already existing instance of Guzzle but your point is valid. Need to look into this. Thanks for pointing this out!
I only glanced at the code on github, so I missed the option key client. So you covered that argument.
I think you don't need to change too much, the library is a good package as a helper in the RAD system of thinking. That is also why Laravel has the guzzle wrapper, and many other helper methods.
And when the time comes that is has been decided that the application needs a more futureproof base, the helpers can be unwrapped and the dependencies can be evaluated.
The only other standalone I could find is github.com/WordPress/Requests. So i think space for well crafted request libraries is not saturated.
It will not be my go to library, but I applaud your effort and I hope to see more of your code.