Update: I spoke with the president of Gigya.
Having only familiarized myself with REST a few months ago, I still struggle to explain to colleagues what REST is. My best one sentence summary so far is that it's "using HTTP as it was designed". Not a perfect or even complete summary, but I think it covers the highlights.
This week I've been reviewing Gigya's REST APIs for an upcoming project at work. And I've found it to be a shining example of designing an API incorrectly and calling it RESTful. It solidified a couple of REST anti-patterns for me and I wanted to capture them:
Many developers coming from a SOAP background think RPC calls can be ported to 'REST' and then call it a day. They are missing a big mental shift in the way to think of web services when designing using REST principles. Instead of thinking of services as functions that can be called, change your thinking to performing operations on objects, formally known as 'resources' in REST parlance. The operations you can perform on your resource are the existing HTTP methods, GET, POST, PUT, DELETE, OPTIONS and HEAD. So instead of exposing a 'setStatus' function via a web service, instead expose a 'status' resource that can be POSTed or PUT to change it, call GET to retrieve the current status, or DELETE it to clear the status. REST is not functional RPC, its a paradigm shift to treating web services in an object-oriented way.
GET is not for state changes
The most important REST principle that Gigya's APIs violate is using GET calls to affect the state of a resource. Short of recording access, like last viewed by/on, GET calls should never affect the state of the resource it represents. If you need to change a resource, there are three other HTTP methods for that purpose, namely POST, PUT and DELETE. The use cases for DELETE are pretty self-apparent, but I've got to admit to being confused of when I should choose POST vs. PUT. John Calcote clarified the answer nicely of when to choose POST over PUT.
The response body is not the only way to send the client information
HTTP headers, for both requests and responses, can be an invaluable way to simplify your API. They can contain rich information about the success (200 OK, 201 Created, 204 No Content) and failure (404 Not Found, 401 Not Authorized, 503 Service Unavailable) of a request. Gigya for example includes the HTTP status code in their XML response body. It seems like a waste of bandwidth to me, when the status code is already included in the response headers. To their credit their documentation seems to imply the codes are more detailed than available in the HTTP spec (500-001, etc) but their examples conflict with that and only show the XML return simple HTTP codes with HTTP reason messages. Even if they provide more detailed information, it should not duplicate what already exists in the request. Trust that your API users can understand and use the headers. Its much easier to only check a status code instead of parsing an XML response.
Authentication is not part of your resource
This antipattern is directly related to my last point of using HTTP headers properly but its important enough to warrant its own bullet. This violation is a version of "don't reinvent the wheel". Gigya has for some strange reason taken OAuth and permuted its use rather than sticking to the spec. They even have API users sign their requests using OAuth libraries but then fail to carry that through into the API usage. The signature a part of the GET query string rather than use the already established HTTP header that the OAuth spec has defined for carrying that data point.
Summary
REST is a very amorphous set of principles but that doesn't mean there are no concrete guidelines. Patterns are emerging as well as anti-patterns and Gigya has examples of both. I don't mean to pick on Gigya but they just happened to be freshest examples in my mind this week. The big points I'd like you to take away from this are, don't reinvent the wheel, use the existing HTTP methods properly, don't forget that HTTP headers exist and design your APIs by thinking of them as objects rather than functions.
Having only familiarized myself with REST a few months ago, I still struggle to explain to colleagues what REST is. My best one sentence summary so far is that it's "using HTTP as it was designed". Not a perfect or even complete summary, but I think it covers the highlights.
This week I've been reviewing Gigya's REST APIs for an upcoming project at work. And I've found it to be a shining example of designing an API incorrectly and calling it RESTful. It solidified a couple of REST anti-patterns for me and I wanted to capture them:
- REST is not RPC, though RPC can be done RESTfully.
- GET is not for state changes. If you're operation has side effects, don't use GET.
- The response body is not the only way to send the client information. Don't duplicate information in the HTTP headers in the response body.
- Authentication is not part of your resource. Don't create a query parameter to do authentication, use the HTTP header that already exists for the purpose.
Many developers coming from a SOAP background think RPC calls can be ported to 'REST' and then call it a day. They are missing a big mental shift in the way to think of web services when designing using REST principles. Instead of thinking of services as functions that can be called, change your thinking to performing operations on objects, formally known as 'resources' in REST parlance. The operations you can perform on your resource are the existing HTTP methods, GET, POST, PUT, DELETE, OPTIONS and HEAD. So instead of exposing a 'setStatus' function via a web service, instead expose a 'status' resource that can be POSTed or PUT to change it, call GET to retrieve the current status, or DELETE it to clear the status. REST is not functional RPC, its a paradigm shift to treating web services in an object-oriented way.
GET is not for state changes
The most important REST principle that Gigya's APIs violate is using GET calls to affect the state of a resource. Short of recording access, like last viewed by/on, GET calls should never affect the state of the resource it represents. If you need to change a resource, there are three other HTTP methods for that purpose, namely POST, PUT and DELETE. The use cases for DELETE are pretty self-apparent, but I've got to admit to being confused of when I should choose POST vs. PUT. John Calcote clarified the answer nicely of when to choose POST over PUT.
The response body is not the only way to send the client information
HTTP headers, for both requests and responses, can be an invaluable way to simplify your API. They can contain rich information about the success (200 OK, 201 Created, 204 No Content) and failure (404 Not Found, 401 Not Authorized, 503 Service Unavailable) of a request. Gigya for example includes the HTTP status code in their XML response body. It seems like a waste of bandwidth to me, when the status code is already included in the response headers. To their credit their documentation seems to imply the codes are more detailed than available in the HTTP spec (500-001, etc) but their examples conflict with that and only show the XML return simple HTTP codes with HTTP reason messages. Even if they provide more detailed information, it should not duplicate what already exists in the request. Trust that your API users can understand and use the headers. Its much easier to only check a status code instead of parsing an XML response.
Authentication is not part of your resource
This antipattern is directly related to my last point of using HTTP headers properly but its important enough to warrant its own bullet. This violation is a version of "don't reinvent the wheel". Gigya has for some strange reason taken OAuth and permuted its use rather than sticking to the spec. They even have API users sign their requests using OAuth libraries but then fail to carry that through into the API usage. The signature a part of the GET query string rather than use the already established HTTP header that the OAuth spec has defined for carrying that data point.
Summary
REST is a very amorphous set of principles but that doesn't mean there are no concrete guidelines. Patterns are emerging as well as anti-patterns and Gigya has examples of both. I don't mean to pick on Gigya but they just happened to be freshest examples in my mind this week. The big points I'd like you to take away from this are, don't reinvent the wheel, use the existing HTTP methods properly, don't forget that HTTP headers exist and design your APIs by thinking of them as objects rather than functions.
Comments
-joe