Ask HN: Why aren't you completely RESTful?

The APIs we create generally aren't _unnecessarily_ RESTful.

Personally, I feel that if we adhere to strongly to REST (or any other technology/platform/architecture) we would be spending too much time thinking about and designing the solution to fit "correctly" into the constraints of REST rather than to solved business problems.

In our scenario:

We only use GET and POST. If the data doesn't have an ID, it's a create. If it does, it's an update. We never delete anything - it's a status change of Active to Inactive.

The only valid HTTP return code is 200. Any other statuses are returned with an error code and descriptive message in an appropriate JSON node.

URIs are never changed or removed, just added. Versioning is handled through use of the API token provided by the client (which is also versioned). Based on your version, the API will call an appropriate implementation.

Some people may argue that this is in fact just RPC disguised as REST. I don't mind. I'd rather use RPC for the sake of solving problems than REST for the sake of REST.