deso-protocol / deso-protocol/backend
Proposal: Improve get-single-profile response consistency and error clarity
- Dominant language
- Go
- Stars
- 139
- Forks
- 84
- PR merge metrics
- No merged PRs in 30d
Description
### 1. Inconsistent response status for missing profiles
When calling the `get-single-profile` endpoint with a valid public key or username that does **not** have an associated profile, the API currently responds with:
- Status: `404 Not Found`
- Response:
```json
{
"error": "GetSingleProfile: could not find profile for username or public key: , BC1YL..."
}
```
**Issue:**
- A `404` implies the endpoint is missing, which is not the case — the user exists, but simply doesn’t have a profile.
- It introduces an inconsistent response shape between users with and without profiles.
- It complicates client-side logic, caching, and error handling.
**Suggested Solution:**
Return a `200 OK` status with a consistent structure such as:
```json
{
"Profile": null,
"IsBlacklisted": false,
"IsGraylisted": false
}
```
### 2. Improve error messaging clarity
When querying by either `Username` or `PublicKeyBase58Check`, the returned error currently includes both fields, even if one was not part of the request:
- Query:
```json
{ "Username": "nader1" }
```
Error:
```json
{ "error": "GetSingleProfile: could not find profile for username or public key: nader1, " }
```
- Query:
```json
{ "PublicKeyBase58Check": "BC1YL..." }
```
Error:
```json
{ "error": "GetSingleProfile: could not find profile for username or public key: , BC1YL..." }
```
**Issue:**
- This adds noise and confusion to error logs and makes debugging more ambiguous.
**Suggested Solution:**
Tailor the error message based on the provided field. For example:
- If only `Username` is provided:
```json
{ "error": "GetSingleProfile: could not find profile for username: nader1" }
```
- If only `PublicKeyBase58Check` is provided:
```json
{ "error": "GetSingleProfile: could not find profile for public key: BC1YL..." }
```
### Summary of proposed improvements:
✅ Use `200 OK` with `Profile: null` when a valid user has no profile
✅ Return only the identifier field actually used in the error
✅ Keep response format consistent whether profile is found or not
These changes would improve developer experience, reduce ambiguity, and allow cleaner client-side integration.
Thanks for considering this enhancement!
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by locating the get-single-profile HTTP handler and its current response and error construction. Compare behavior for Username, PublicKeyBase58Check, and users without profiles against the examples; done means the 200/null response and identifier-specific errors are covered by endpoint tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100