deso-protocol / deso-protocol/backend

Proposal: Improve get-single-profile response consistency and error clarity

Open
#733 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.