-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling POST requests #32
Comments
@sdbondi It isn't clear if @weluse would accept a PR for this. I'm definitely interested in adding this capability. For the moment, I guess we have your comment about Interestingly, I have a whole bunch of PRs pending for the |
The It seems to be considered best practice/standard for resource creation to include a
I am working my way through building a HAL api with |
On the topic of |
I just added my thoughts about |
Hello folks! When I use POST (like signing up my user) on (http://haltalk.herokuapp.com/), the method you described above works good but the
|
This isn't really an issue but more of a question (that might highlight an issue...but I'm not sure).
I've created a HAL based API. So hyperagent seems well suited for that. I don't 100% understand when I'm supposed to
fetch
and when I'm not, but that is a separate, manageable issue.The main issue I'm having is with handling
POST
requests. There are cases where I have to do aPOST
to create resources on the server. I'm aware of the "dialects" to HAL for such things, but I'm not using those (at least in this case) because I'm uploading files and I don't think HAL makes any sense in that context (although correct me if I'm wrong).Being a good REST api, the
POST
returns a 201 status and aLocation
header. But in ahyperagent
context, that is just another URL, not a properResource
object. What I do now is basically:So basically, I read the
Location
header of thePOST
response (which is just that path portion), combine that with the base_url for the API to get a fully qualified URL and then create a newResource
object from that. This feels odd to me because I feel that when I stay in the realm ofGET
, I only have to create one "api"Resource
and I can navigate entirely from there (which is how it should be, right).But here, I have to start messing around with URLs again, which is exactly what I was hoping to avoid with a very hypermedia centric API. The strange thing is...why should a
POST
complicate things. TheLocation
header is a standard way to return the URL of a new resource. Why not take advantage of that somehow? I didn't see any reference to theLocation
header anywhere in the hyperagent source so it doesn't seem like this is taken into account.What I envision is something like this:
The idea here would be a method,
post
, that (behind the scenes) makes aPOST
request to thefiles
resource, parses theLocation
header (like I've done above?) and then returns the resource. In this way, the client code looks clean and avoids all this URL handling?Is this the "proper" way to go about this or am I missing something. I'm happy to do the work and submit a PR. I just want to make sure a) I'm not doing it wrong, b) there isn't already a way to do this cleanly and c) if it were to be done that this is the way to do it.
Comments?
The text was updated successfully, but these errors were encountered: