requests.http

Overview

This file contains a collection of HTTP request examples primarily designed for testing or interacting with message-related REST API endpoints across different API versions and hosts. The requests focus on the POST method to submit messages to various /messages endpoints, showcasing typical payloads, headers, and authentication schemes. The file also includes examples of valid and intentionally malformed requests to demonstrate different server responses, such as successful message creation and bad requests.

Request Definitions

Variables

• @port = 3000
  Defines the default port number used in request URLs.

• @host = http://localhost
  Sets the base URL for the requests.

• @v1 = v1 and @v2 = v2
  Represent API version segments used in the request paths.

Requests

1. POST to /v1/messages

• Request line:
  POST {{host}}/{{v1}}/messages HTTP/1.1

• Headers:
  Content-Type: application/json

• Body:
  An empty JSON object {}.

• Purpose:
  This request submits a message to the version 1 API endpoint. The empty body suggests either a placeholder or an initial test for the endpoint's handling of empty payloads.

• Usage example:

POST http://localhost/v1/messages HTTP/1.1
Content-Type: application/json

{}

2. POST to /v2/messages

• Request line:
  POST {{host}}/{{v2}}/messages HTTP/1.1

• Headers:
  Content-Type: application/json

• Body:
  An empty JSON object {} similar to the v1 request.

• Purpose:
  Tests or interacts with the version 2 API endpoint for message submission, again with an empty payload.

• Usage example:

POST http://localhost/v2/messages HTTP/1.1
Content-Type: application/json

{}

3. Bad Request Example

• Request line:
  POST http://localhost/bm/v2/messages HTTP/1.1

• Headers:
  Content-Type: application/json

• Body:
  A JSON array with a single object containing id: null, a long boc string, and expire: null:

  [{"id":null,"boc":"te6ccgEBAwEArAAB5YgAIiI...","expire":null}]
  

• Purpose:
  Demonstrates a malformed or invalid request likely to trigger a "Bad Request" response due to a null id field or other schema violations.

• Notes:
  The path includes /bm/v2/messages, which might indicate a different service or API context.

4. Valid POST to /bm/v2/messages on port 8700

• Request line:
  POST http://localhost:8700/bm/v2/messages HTTP/1.1

• Headers:
  Content-Type: application/json

• Body:
  A JSON array containing an object with detailed message fields:

  • id: a long hex string

  • body: a base64-like string representing message content

  • expire_at: null

  • thread_id: zeroed 64-character hex string

  • bm_pubkey: null

  • ext_message_token: null

• Purpose:
  Sends a valid message payload to the bm service at version 2, possibly for message storage or processing. The use of port 8700 suggests a different microservice or environment.

• Usage example:

POST http://localhost:8700/bm/v2/messages HTTP/1.1
Content-Type: application/json

[{
    "id":"ee4ca4f6ddb38b572f118d9d5d564fe0960fc0fe3a29737ff8e8713bf329db69",
    "body":"te6ccgEBAwEArAAB5YgAIiI...",
    "expire_at":null,
    "thread_id":"00000000000000000000000000000000000000000000000000000000000000000000",
    "bm_pubkey":null,
    "ext_message_token":null
}]

5. Authenticated POST to /bk/v2/messages on port 11003

• Request line:
  POST http://localhost:11003/bk/v2/messages HTTP/1.1

• Headers:

  • Content-Type: application/json

  • Authorization: Bearer my-secret-token

• Body:
  Similar to the previous message body, with fields id, body, expire_at, thread_id, bm_pubkey, and ext_message_token.

• Purpose:
  This request demonstrates how to submit a message to a bk service version 2 endpoint, which requires bearer token authentication. This is indicative of an endpoint with secured access controls.

• Usage example:

POST http://localhost:11003/bk/v2/messages HTTP/1.1
Content-Type: application/json
Authorization: Bearer my-secret-token

[{
    "id": "4d5772b75a413327386aabf4bfb53acd58279c26b19dea5d8325a635fc7c3aee",
    "body": "te6ccgEBAwEArAAB5YgAIiI...",
    "expire_at": null,
    "thread_id": "00000000000000000000000000000000000000000000000000000000000000000000",
    "bm_pubkey": null,
    "ext_message_token": null
}]

Important Implementation Details

• Variable Replacement:
  The file uses variable placeholders ({{host}}, {{v1}}, {{v2}}) to allow easy modification of request URLs for different environments or API versions.

• Message Format:
  The requests submitting messages use JSON arrays containing message objects with specific fields such as id, body, expire_at, thread_id, bm_pubkey, and ext_message_token. The body field contains encoded data likely representing serialized or encrypted message contents.

• Authentication:
  Only the request to the /bk/v2/messages endpoint includes an Authorization header, indicating selective access control on certain endpoints.

• Port Variation:
  Requests target different ports (3000, 8700, 11003), suggesting multiple services or microservices running locally, each responsible for handling different API paths or versions.

• Error Handling Demonstration:
  The “BAD REQUEST” section illustrates how invalid payloads (such as id: null) can be used to test server-side validation logic.

Interaction with Other System Components

• API Versioning:
  Differentiation between v1 and v2 APIs allows the system to evolve while maintaining backward compatibility.

• Microservice Communication:
  Separate ports and path prefixes (bm, bk) imply distinct services handling messages, possibly with different responsibilities such as message broker (bm) and backend service (bk).

• Security Layer:
  The presence of bearer token authorization on some endpoints suggests integration with an authentication and authorization system.

• Message Lifecycle:
  Fields like expire_at and thread_id relate to message lifecycle and threading, linking this file’s requests to broader topics like message persistence and threading management.

Visual Diagram

flowchart TD
A[Start] --> B[POST /v1/messages]
A --> C[POST /v2/messages]
A --> D[POST /bm/v2/messages on port 8700]
A --> E[POST /bk/v2/messages on port 11003]
A --> F[POST /bm/v2/messages Bad Request]
B --> G{Empty JSON body}
C --> G
D --> H{Valid message payload}
E --> I{Valid message payload + Auth}
F --> J{Invalid message payload}
style B fill:#bbdefb,stroke:#1e88e5
style C fill:#bbdefb,stroke:#1e88e5
style D fill:#c8e6c9,stroke:#388e3c
style E fill:#c8e6c9,stroke:#388e3c
style F fill:#ffcdd2,stroke:#d32f2f