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 HATEOAS.
• Supports HTTP Basic Auth, Query parameter and HTTP Bearer Tokens
• Custom rate limiting feature.
• Web interface for data management.

Public Resources

Trying it Out.

• GET /public-api/users/: list all users.
• GET /public-api/users/?name=john: list all users with 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/ and PUT /users/123: update the user 123.
• DELETE /public-api/users/123/: delete the user 123.

Try Rest Console

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

NOTE: All api calls unless listed in "Public Resources" will require a access-token.

Limited Fields and Extra Data

                    
Customize the output fields, also get the relational data in single call

// only returns fields id and email
http://gorest.co.in/public-api/users?fields=id,email

// returns all fields of user with posts
http://gorest.co.in/public-api/users?expand=posts

// returns all fields of user with albums and posts
http://gorest.co.in/public-api/users?expand=albums,posts

// only returns user fields id and email with user posts
http://gorest.co.in/public-api/users?fields=id,email&expand=posts
                

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.

Error Response

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.