I am trying to get the (new) body from an edited issue comment. I don't know if I am missing something here, but it seems that the webhook payload returned with an edited issue comment, contains only the old comment... There is no way to tell what was changed.
What I do at the moment, is when I get an issue comment event with an action "edited", to make a get request for this comment in order to retrieve its body.
Is this how it's supposed to be? I find it strange that I need to make a new request for something that should already be in the issue comment payload.
There are some issues with webhook content returning old data, presumably due to caching and/or replication issues in GitHub's backend. GitHub support themselves have confirmed to me that this can happen.
The only workaround right now is to fetch the comment content in a separate API request after some small delay in order to allow the updated comment body to propagate through GitHub's backend (the bug affects API requests as well as webhook events, annoyingly).
Related
I was asked below question in the Interview -
If you are hitting the same request with PUT and with POST http method then what will be the difference in payload?
Considering I don't have much experience working in REST, I didn't even know what payload is. I tried googling but didn't find anything conviencing.
Can anyone help?
according to this page restfulapi.net the PUT request should refer to already existing item (for example in a database connected). In other words, it is meant to update existing item. So the payload don't have to contain all the attributes of the item, just those you want to update.
On the other hand POST is meant to insert new item. This means that the payload should contain (almost) everything.
Thing is, if you send more same PUT requests, the item should remain equivalent to the situation with just one PUT send.
If you send two same POST requests then two new same items (with different ids) will be created. This means that POST requests are not idempotent.
Edit: here might be help too.
I didn't even know what payload is.
The interviewer is probably referring to the message-body of the HTTP Request (see RFC 7230).
If you are hitting the same request with PUT and with POST http method then what will be the difference in payload?
This is probably an attempt to explore whether you understand the difference in semantics between the HTTP POST method and the HTTP PUT method.
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.
Think "save file".
The instructions for POST are a lot less specific
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.
If that seems vague... you're right! The message-body of a POST request can mean almost anything. POST is the "junk drawer" of HTTP methods - anything not worth standardizing goes there.
This question already has answers here:
HTTP GET with request body
(23 answers)
Closed 2 years ago.
I've been looking at how to implement the following:
I am developing a RESTful Web API (using .Net Core 2.2). I need to create an endpoint where the consuming client can send some text to the API, the API replaces some tokens in this text, and returns the text back to the consuming client.
I thought that the client should simply do a GET request, with the text in the body. The reply would then be the new text after the token replacements. However, from my research, it appears one should not stick anything with semantics in the body of a GET request. I'm not sure if arbitrary text with certain tokens that need to be replaced by the API qualifies as semantic? I've also seen it stated at "you should not be able to use the body of a GET request to alter the response". I guess I'm in trouble there, as depending what goes into he body, will affect the response.
So then, I've been struggling to figure out what is the correct way to do this. If anyone has an pointers I'd greatly appreciate it.
Thank you.
I thought that the client should simply do a GET request, with the text in the body. The reply would then be the new text after the token replacements. However, from my research, it appears one should not stick anything with semantics in the body of a GET request.
Right - RFC 7231
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
In basic HTTP, you've got choices. One is to include a representation of your document in the URI itself
/?your_document_as_a_query_string
/your/document/as/path/segments
For short documents, that approach can be fine; but implementations are not required to support infinitely long identifiers, so you may discover that intermediate components reject your request, or crop the URI in transit.
A safe mechanism for achieving your goal is to use POST, rather than GET. POST supports a message body, so you can send the blank form to the server, and receive back the edited version in the response.
POST is the wildcard method of HTTP, it can mean anything. In the spec, the body of the response includes "a representation of the status of, or results obtained from, the action".
You might also consider that the response duplicates a lot of the content of the body of the request, and consider instead the possibilities of fetching a map of your template values from the server, and then applying the template on the client.
I have a webhook on issues for github and I update the body of the issue from within my application using PATCH request. The rate is not very fast, like a request every few seconds. Most of the times it works, yet some of the times GitHub sends my hook a nonsense payload which has the body text before my edit in both body and changes.body.from fields as if there was a change which changed nothing. At the same time:
The responce to my PATCH displays new body correctly.
The issue itself on GitHub gets updated properly.
No follow up webhook procs with correct body happen.
Anybody has an idea what I could be hitting here?
Thanks in advance.
Is there any possibility of "listening" to the state of GET SiteCatalyst image requests ?
I'd like to run a callback function only when the requests are over, to be more clear when they receive the 200 status code and I'm sure they're done.I'm confident no "built-in" method is available and maybe I should hack the core s.track.s.t() function...?Thanks a lot.
You are right, there is no global "built-in" callback method for when the Adobe Analytics request is complete.
A couple notes I should mention to you about attempting to hack the core code:
1) If you are using the AppMeasurement library version 1.4.1+, in some circumstances, a POST request may be made instead of an image request.
2) Responses that are not 200/OK or otherwise completed/successful does not necessarily mean the data failed to be sent to Adobe. Most common scenario is a NS_BINDING_ABORTED error returned.
The main bad effect I'm getting here is what I previously thought as a double XHR request.
It wasn't. In reality the first request gets redirected as it would be the first visit of a new visitor (302 status) and a new visitorID is brought down by Adobe server.
Then the redirected "200 status" request is made with this new visitorID within.This is bad because every XHR requests would result in a new visit of a new visitor even though a previously set "s_vi" cookie is there in browser, with the lack of previous collected data for that user.I know what XHR redirects couldn't be blocked so I'm wondering if there is a way to "tell" Adobe server it's not the first request ever made, in order to stop the redirect and do not use a new visitorID.
I'm designing a REST API. Some methods of this API are used to insert new data using the POST method. I'm wondering what error code to return when the insertion would result in duplicate data being inserted? I tried looking at the error code reference, but being quite new to REST and HTTP I'm not sure which one to use.
409 Conflict seems appropriate for that case.
The W3C status code definitions document says:
10.4.10 409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.