updateuser

/updateuser/ endpoint in QA

/updateuser/ endpoint in SWAGGER-UI

curl -X 'PUT' \ 'http://peviitorqa.go.ro/api/v0/updateuser/?id=<string>&url=<string>&company=<string>&logo=<string>&apikey=<string>' \ -H 'accept: application/json'

---

---

Technical Documentation

Request and Response Structure

• Method: PATCH

• Endpoint name: /updateuser

• Request Parameters:

  • apikey (required) – The API key assigned to the user.
  • id – The unique identifier for the user (email address encoded as a URL parameter).
  • url – The company's careers page URL.
  • company – The company associated with the user.
  • logo – The logo URL of the company.

• Response Format: application/json; charset=utf-8

Expected Data Format

Request Body

{
    "id": "<string>",
    "url": "<string>",
    "company": "<string>",
    "logo": "<string>",
    "apikey": "<string>"
}

List of Status Codes and Error Messages

• 200 OK – Request successful, the user document was updated.
• 400 Bad Request – Invalid request parameters or missing required fields.
• 401 Unauthorized – Authentication is required or invalid credentials.
• 403 Forbidden – Access denied due to insufficient permissions.
• 404 Not Found – No user found with the specified apikey.
• 405 Method Not Allowed – Only PATCH requests are supported.
• 500 Internal Server Error – An unexpected error occurred on the server.
• 502 Bad Gateway – The primary and fallback servers are both unreachable.
• 503 Service Unavailable – The SOLR server is down or unreachable.
• 507 Insufficient Storage – SOLR or API server runs out of space/memory.

{
    "error": "<message>",
    "code": <number>
}

Business Logic Applied

• Fetches user data from the SOLR search index (auth core).
• Identifies user using the apikey and returns a 404 Not Found if no match.
• Updates only the fields provided in the request payload while preserving other fields.
• On successful update, the modified document is returned in the response.

Security Measures

• CORS policy: Open to all (Access-Control-Allow-Origin: *).
• Authentication & Authorization: Not implemented in the current version.
• Rate Limits: Not specified but should be considered for production environments.

Dependencies

• SOLR Search Server – Required to fetch and update user data.
• PHP file_get_contents function – Used to communicate with the SOLR server.

Known Limitations & Edge Cases

• SOLR Downtime: If SOLR is unavailable, API returns a 503 error.
• Empty Dataset: If no user exists with the given API key, a 404 Not Found is returned.
• Non-empty Fields: All provided fields must contain valid, non-empty strings.
• Unique Values: API keys must be unique for each user.
• Invalid ID Format: Missing or invalid apikey values return a 400 Bad Request error.
• Security Risks: API keys and updated data are echoed in the response. Secure handling is advised.
• To do: Implement authentication for accessing user data.
• To do: Secure SOLR with security.json.
• To do: Protect SOLR by IP whitelist.

---

---

Business Requirement Document: Update User Information Endpoint

Objective:

The objective of this project is to develop an API endpoint that updates user information in a SOLR index. This endpoint will be used to modify specific user details based on a unique identifier.

Key Requirements:

1. Functionality:

   • The endpoint should accept an apikey and updated field values as input (it should receive in body apikey and at least one more field).
   • It should update the corresponding user's information in the SOLR index.
   • The endpoint should support updating fields such as URL, company, logo, and id.

2. Error Handling:

   • The endpoint should handle errors gracefully, providing meaningful error messages to users.
   • Specific error handling should include scenarios where no user identifier is provided, the user is not found, or the update operation fails.

3. User Experience:

   • The endpoint should respond quickly to ensure a seamless user experience.
   • The response should include the updated user information.

4. Data Integrity:

   • Ensure that the updated user data is accurate and consistent.
   • The endpoint should only update data for the specified user.

5. Security:

   • Implement appropriate security measures to protect user data and prevent unauthorized access to the SOLR index.

6. Scalability:

   • The endpoint should be designed to handle a high volume of requests without impacting performance.

Acceptance Criteria:

• The endpoint successfully updates user information in the SOLR index based on the provided identifier and updated fields.
• The endpoint returns the updated user data.
• Error messages are clear and informative for users.
• The endpoint responds within an acceptable time frame.

Assumptions and Dependencies:

• The SOLR index is properly configured and populated with user data.
• Necessary infrastructure and resources are available to support the endpoint.

Risks and Mitigation Strategies:

• Risk: Technical issues with the SOLR index could prevent updates from being applied.

  • Mitigation: Regularly monitor the SOLR index for errors and perform maintenance as needed.

• Risk: High traffic could impact performance.

  • Mitigation: Implement load balancing and optimize server resources to handle increased traffic.

• Risk: Unauthorized access could lead to data breaches.

  • Mitigation: Implement robust security measures, including authentication and authorization checks.

---