Online REST API for Testing and Prototyping

Features:

• Fully secured quick prototyping.
• Response format negotiation. (supporting JSON and XML)
• Support for selectable output fields.
• Full search support on all fields
• Proper formatting of collection data and validation errors.
• Support for the OPTIONS and HEAD verbs;
• Support for HATEOAS.
• Supports HTTP Basic Auth, Query parameter and HTTP Bearer Tokens
• Custom rate limiting feature.
• Web interface for data management.
• Usage history (basic troubleshooting for your requests)

Resources

Trying it Out.

• GET /public-api/users: list all users.
• GET /public-api/users?first_name=john: list all users with first_name contains john.
• POST /public-api/users: create a new user.
• GET /public-api/users/123: return the details of the user 123.
• PATCH /public-api/users/123 or PUT /public-api/users/123: update the user 123.
• DELETE /public-api/users/123: delete the user 123.
• For paged result set parameter "page" should be passed in url ex: GET /public-api/users?page=5 will get 5th page results. If non existing page number is passed then last page results will be returned.

List of Supported Verbs.

• HEAD /public-api/users: show the overview information of user listing.
• HEAD /public-api/users/123: show the overview information of user 123.
• OPTIONS /public-api/users: show the supported verbs of endpoint
• OPTIONS /public-api/users/123: show the supported verbs of endpoint

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=xxxxxxxx.
• 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.
• NOTE: To prevent abuse all API calls requires a access-token, which can be obtained by a free registration.
• Try Rest Console now

cUrl Examples

                    
1. Create new user
curl -i -H "Accept:application/json" -H "Content-Type:application/json" -H "Authorization: Bearer YOUR-ACCESS-TOKEN" -XPOST "https://gorest.co.in/public-api/users" -d '{"first_name":"Brian","last_name":"Ratke","gender":"male","email":"lew19@roberts.com","status":"active"}'

2. Update existing user with id 123
curl -i -H "Accept:application/json" -H "Content-Type:application/json" -H "Authorization: Bearer YOUR-ACCESS-TOKEN" -XPATCH "https://gorest.co.in/public-api/users/123" -d '{"first_name":"Brian","last_name":"Ratke","email":"lew19@roberts.com","status":"active"}'

3. Delete user with id 123
curl -i -H "Accept:application/json" -H "Content-Type:application/json" -H "Authorization: Bearer YOUR-ACCESS-TOKEN" -XDELETE "https://gorest.co.in/public-api/users/123"
                

Guzzle Http Examples

                    
1. GET request with query parameter authentication:
new GuzzleHttp\Client()->request('GET', 'https://gorest.co.in/public-api/posts?access-token=YOUR-ACCESS-TOKEN', ['verify' => false]);

2. PATCH request with HTTP Bearer Tokens
new GuzzleHttp\Client()->request('PATCH', 'https://gorest.co.in/public-api/users/1', ['verify' => false, 'headers' => ['Authorization' => 'Bearer YOUR-ACCESS-TOKEN'], 'json' => ['first_name' => 'Reynolds', 'last_name' => 'Lockman', 'gender' => 'female']]);

2. DELETE request with HTTP Bearer Tokens
new GuzzleHttp\Client()->request('DELETE', 'https://gorest.co.in/public-api/users/1', ['verify' => false, 'headers' => ['Authorization' => 'Bearer YOUR-ACCESS-TOKEN']]);


                

Response Codes

The following list summarizes the HTTP status codes that are used.

• 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.