2016-10-03 1 views
0

상태 업데이트 PUT 요청을 수행하려고합니다. 다음의 예는 우체부 200을 반환개조 2 : 400 바디가있을 때 잘못된 요청

URL :

http://www.example.com/users/3/status?seId=1&dt=2016-11-01T00:00:00Z

HEADERS :

콘텐츠 형식 : 응용 프로그램/JSON

문자셋 : UTF-8

권한 : 베어러 LONG_TOKEN_HERE

BODY :

{ "상태는"1}

이 구조 내 개조 2 요청 :

@PUT("users/{id}/status") 
Call<Void> updateEventStatus(@Header("Authorization") String token, 
          @Path("id") int id, 
          @Query("seId") int seId, 
          @Query("dt") String dateTime, 
          @Body Status status); 

요청 URL은 우편 배달부와 동일하므로 머리글도 있으므로 본문과 관련이 있다고 생각됩니다. Statusthis answer을 따라 만든 status이라는 단일 int 필드가 포함 된 래핑 클래스입니다 (동일한 자격 증명을 사용하고 잘 작동 함). 나는 또한 int 유형의 본문에 상태를 만들려고했으나 잘못된 요청도 발생합니다.

Postman 요청과 Retrofit 2 요청의 차이점은 무엇입니까? 감사! EDIT

:이 개조 2의 originalRequest이다

Request{method=PUT, url=http://example.com/api/users/3/status?seId=0&dt=2016-10-04T05:30:00Z, tag=null} 

headers: Authorization: Bearer LONG_TOKEN_HERE 

contentType: application/json; charset=UTF-8 

content: 

0 = 123 
1 = 34 
2 = 115 
3 = 116 
4 = 97 
5 = 116 
6 = 117 
7 = 115 
8 = 34 
9 = 58 
10 = 51 
11 = 125 

Translated content: 
{"status":3} 
+0

'updateEventStatus'에 전달한'token'은 "Bearer"+ LONG_TOKEN_HERE입니다. –

+0

그래요, 거의 모든 방법에서 사용하고 있습니다. –

+0

개조를 통해 요청을 게시 할 수 있습니까? –

답변

0

결국 이것은 서버 측 버그 (I 처음에 거짓 SEID를 수신 한 다음 SEID를 사용 으려고였습니다 존재하지 않습니다).