I was stressful whenever my teammates, talented developers, share the curl, which including the secret credentials like - Authorization Token, for detecting and resolving the issues. So, I am curious that how you guys do that ? There have any better way to send an API bug report ?

Updated:

--

I think that way is not secure enough. For example, I can use Secret Token, which is exposed in curl, to do something like ~ buying my own stuff .

So, there have anyway to secure the curl ? But we are still easy to detect the API issue.

What? Why is it a real problem?

If you don't like curl, think maybe you're more of a postman person?

I think that way is not secure enough. For example, I can use Secret Token, which is exposed in curl, to do something like ~ buying my own stuff .

So, there have anyway to secure the curl ? But we are still easy to detect the API issue.

Maybe when they share it, replace the secret with a shell variable? Solved!

I thought about that way. But, we can't re-produce or see the API's response. So, it so hard to detect the API's issue, right :?

What real problem does the sharing cause?

Sorry, maybe I don't say clearly enough :(. Let show some code, hope it easy to understand.

I found that, the order listing API doesn't work as expected. I send the curl to my teammate. Please take a look at `-H 'X-Access-Token: SECRET_TOKEN' \`

```

curl 'https://mocha.lozi.vn/v6/users/me/orders' \ -X GET \ -H 'X-Access-Token: SECRET_TOKEN' \ -H 'Host: mocha.lozi.vn' \ -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Firefox/101.0' \ -H 'Accept: /' \ -H 'Accept-Language: vi_VN' \ -H 'Accept-Encoding: gzip, deflate, br' \ -H 'X-Lozi-Client: 1' \ -H 'X-City-ID: 50' \ -H 'Origin: https://loship.vn' \ -H 'Connection: keep-alive' \ -H 'Referer: https://loship.vn/' \ -H 'Sec-Fetch-Dest: empty' \ -H 'Sec-Fetch-Mode: cors' \ -H 'Sec-Fetch-Site: cross-site'

```

The problem is:

1/ If I don't replace the real token by SECRET_TOKEN, others can use it to buying their own stuffs, by my token. :(

2/ If I replace the real token by SECRET_TOKEN, it's so hard to detect what the problem is, cause my teammate can't see the response, and can't request to re-produce the issue too.

Actually, I'm a terminal guy, and I like to use curl than postman

What do you think would be the ideal? A way for someone to replay an API request (without seeing it) in a dev environ?

yes, thinking about that. Actually, an API bug report should be:

1/ secured, the credentials should not be exposed.

2/ enough information, e.g. the response must be snapshot, general parameters should be transparent.

3/ easy to re-produce and confirm resolved.

What do you think?

It makes sense. I think one of the challenges is the question of how much you need to store in order to be able to do this. Hanging onto every request/response object / parameters for an interaction with an API can be become expensive pretty quickly.

This becomes an issue when you start thinking about what is considered to be a bug. If you're just talking about error codes, then you're probably fine to store everything. But when you talk about unexplained (but not erroneous) behaviour from the API, how much you need to store to catch the bugs is an important consideration.

Agree! That's why I think a centralize tracing system is too expensive. Still looking for a better way to send API bug report.

Why don't APIs have a general path for reporting API errors?

How does it works ? Could you give some example please :D

I would imagine setting a header or query param to trigger better tracing and submission to an bug reporter could be generally useful.

Ah, I got some ideal here. So, you mean:

1/ We should have an API tracing system, hosted in a server for example, which capture all requests, including the params, headers, response. with some secure rule, e.g. hide Secret-Token header.

2/ Each request will have a header, its value is the request-id for example

3/ Whenever a bug come, we just need use request-id from 2/ and search the information in 1/

Right ?

I can't think of why not, besides the overhead with tracing .. but I already do tracing on my apps so I could do this very easily.

I built several tracing systems, but none of them capturing & storing the API's response, cause too expensive, you know. Could you share more about your tracing system? I think we can learn from others.