How does RESTful service handle different media types for the same resource?

How does RESTful service handle different media types for the same resource?

• A. By only supporting JSON
• B. Based on the "Accept" header parameter
• C. By static URL for resources
• D. By limiting responses to XML only

Answer: (B)

RESTful services utilize the "Accept" header parameter to handle different media types for the same resource, allowing clients to specify the format in which they wish to receive the response. This capability is fundamental to REST’s flexibility, as it enables the same endpoint to serve various representations of the same resource, such as JSON, XML, or HTML, depending on the client's preferences and capabilities as indicated in the request. For example, a client that sends a request with the "Accept" header set to "application/json" expects a response in JSON format, while another client requesting "application/xml" would receive the same resource in XML format. This approach facilitates a more scalable and adaptable API design, as it supports multiple formats and maintains a single resource representation while catering to diverse client needs. The other options fail to recognize the versatility of REST. Supporting only JSON would limit the interaction capabilities for clients needing different formats. Static URLs for resources would not accommodate different media types and would complicate the API's structure and user experience. Finally, limiting responses to XML excludes other widely-used representations, which is contrary to the fundamental design principles of RESTful services.

RESTful services utilize the "Accept" header parameter to handle different media types for the same resource, allowing clients to specify the format in which they wish to receive the response. This capability is fundamental to REST’s flexibility, as it enables the same endpoint to serve various representations of the same resource, such as JSON, XML, or HTML, depending on the client's preferences and capabilities as indicated in the request.

For example, a client that sends a request with the "Accept" header set to "application/json" expects a response in JSON format, while another client requesting "application/xml" would receive the same resource in XML format. This approach facilitates a more scalable and adaptable API design, as it supports multiple formats and maintains a single resource representation while catering to diverse client needs.

The other options fail to recognize the versatility of REST. Supporting only JSON would limit the interaction capabilities for clients needing different formats. Static URLs for resources would not accommodate different media types and would complicate the API's structure and user experience. Finally, limiting responses to XML excludes other widely-used representations, which is contrary to the fundamental design principles of RESTful services.