Online REST API for Testing and Prototyping
data | real responses | 24/7 online
Trying it Out
| POST /public-api/users | Create a new user |
| GET /public-api/users/123 | Get user details |
| PATCH /public-api/users/123 | Update user details |
| PUT /public-api/users/123 | Update user details |
| DELETE /public-api/users/123 | Delete user |
| OPTIONS /public-api/users | Preflight request |
| HEAD /public-api/users | Headers only |
Nested Resources
| POST /public-api/users/123/posts | Creates a user post |
| POST /public-api/posts/123/comments | Creates a post comment |
| POST /public-api/users/123/todos | Creates a user todo |
- For paged results parameter 'page' should be passed in url ex: GET /public-api/users?page=5
- Do not save/post your personal data like name, email, phone, photo etc...
- Request methods PUT, POST, PATCH, DELETE needs access token, which needs to be passed in "Authorization" header as Bearer token.
- Click here to get your access token
Features
- Fully secured quick prototyping.
- Response format negotiation. (supporting JSON and XML add ".json" or ".xml" to api end point)
- Proper formatting of collection data, validation errors and meta data.
- Support for the OPTIONS and HEAD verbs.
- Full search support on all fields. Ex: https://gorest.co.in/public-api/users?name=varma
Authentication
Unlike Web applications, RESTful APIs are usually stateless, which means sessions or cookies should not be used. Therefore, each request should come with some sort of authentication credentials. A common practice is to send a secret access token with each request to authenticate the user. Since an access token can be used to uniquely identify and authenticate a user, API requests should always be sent via HTTPS to prevent man-in-the-middle (MitM) attacks.
There are different ways to send an access token:
- HTTP Basic Auth: the access token is sent as the username.
- Query parameter: the access token is sent as a query parameter in the API URL.
e.g. https://gorest.co.in/public-api/users?access-token=xxx - OAuth 2: the access token is obtained by the consumer from an authorization server and sent to the API server via HTTP Bearer Tokens , according to the OAuth2 protocol.
- This API supports only HTTP Bearer Tokens
cUrl Examples
1. List users
curl -i -H "Accept:application/json" -H "Content-Type:application/json" -XGET "https://gorest.co.in/public-api/users"2. Create user
curl -i -H "Accept:application/json" -H "Content-Type:application/json" -H "Authorization: Bearer ACCESS-TOKEN" -XPOST "https://gorest.co.in/public-api/users" -d '{"name":"Tenali Ramakrishna", "gender":"Male", "email":"tenali.ramakrishna@15ce.com", "status":"Active"}' 3. Update user
curl -i -H "Accept:application/json" -H "Content-Type:application/json" -H "Authorization: Bearer ACCESS-TOKEN" -XPATCH "https://gorest.co.in/public-api/users/123" -d '{"name":"Allasani Peddana", "email":"allasani.peddana@15ce.com", "status":"Active"}' 4. Delete user
curl -i -H "Accept:application/json" -H "Content-Type:application/json" -H "Authorization: Bearer ACCESS-TOKEN" -XDELETE "https://gorest.co.in/public-api/users/123"Http Response Codes Summary
- 200: OK. Everything worked as expected.
- 201: A resource was successfully created in response to a POST request. The Location header contains the URL pointing to the newly created resource.
- 204: The request was handled successfully and the response contains no body content (like a DELETE request).
- 304: The resource was not modified. You can use the cached version.
- 400: Bad request. This could be caused by various actions by the user, such as providing invalid JSON data in the request body, providing invalid action parameters, etc.
- 401: Authentication failed.
- 403: The authenticated user is not allowed to access the specified API endpoint.
- 404: The requested resource does not exist.
- 405: Method not allowed. Please check the Allow header for the allowed HTTP methods.
- 415: Unsupported media type. The requested content type or version number is invalid.
- 422: Data validation failed (in response to a POST request, for example). Please check the response body for detailed error messages.
- 429: Too many requests. The request was rejected due to rate limiting.
- 500: Internal server error. This could be caused by internal program errors.