Amazon SimpleDB's non-REST API

Making REST Requests: "Amazon SimpleDB REST calls are made using HTTP GET requests. The Action query parameter provides the method called and the URI specifies the target of the call. Additional call parameters are specified as HTTP query parameters. The response is an XML document that conforms to a schema."

This is not unlike shipping a database that lets you update by embedding actions in SELECT statements. The underlying issue here is the uniformity of the GET method across the web - what clients and intermediaries are allowed to assume about it. Here's the basic advice on GET and POST from the W3C:

"

  • Use GET if:
    • The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
  • Use POST if:
    • The interaction is more like an order, or
    • The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    • The user be held accountable for the results of the interaction.

However, before the final decision to use HTTP GET or POST, please also consider considerations for sensitive data and practical considerations."

Designing in side-effects to GET requests is a  fundamental mistake of web development that people who don't understand the web/http tend to make. It's less common now than it used to be, but I'm suprised to see it in a web API from one the biggest web properties and doubly surprised to see it called "REST".  This is pity as the commercial and technical properties of the database itself are interesting. Ascribing REST to the SimpleDb API might be down to lack of knowledge or marketecture; hopefully they'll get the API* sorted out soon, before it gets used heavily. See also Keith Gaughan's observations, which extend to SQS and FPS.

For an example of a better design for this class of problem, see Google code's use of subversion. Now, I know that  svn over dav isn't normally promoted as an API, but it is.

The other downside is the way the privately defined markup is tied to the operations - stuff like "PutResponse" is quite the turn-of-the-century-webservices way of doing things. I spend a good bit of time looking at markup like in that the mobile space. It all could be a good deal simpler.

 


* by "API" here, I mean an application protocol interface.

Tags:

8 Comments


    Yep. IMO, the potential is there for Amazon to set principled web design back three to five years if SimpleDB gets traction under its current design. Sad.


    Wow, talk about hyperbole, Ryan..

    All of us REST people may love a brilliantly concise method + URI structure, but for the rest of the world, plain old GET + cache-busting headers works ok. It's a shame, but that's life.


    What I believe you will find most interesting is when you hear from the powers that be that the fastest, most efficient, and most effective way to interact with SimpleDB is via SOAP.

    I love REST as much as the next RESTaholic, but there are plenty of use-cases in which REST doesn't fit nice and snug into. Performing operations in which require massive amounts of data (speaking relatively in HTTP GET/POST terms) to be associated with each attribute (you can have up to 256 attributes per key, 1k of data per attribute entry, each attribute can have unlimited number of entries up to the limit of the domain itself (10 Gigs)) becomes seriously problematic using HTTP+REST.

    Of course one might argue "just stick it in the payload" but why develop your own messaging envelope format when one, that just so happens to be standardized, already works and works well for the use-case at hand? Isn't that what standards are all about? And wouldn't Amazon be criticized for creating their own messaging infrastructure that mimicked SOAP if they chose to do just that?

    One could argue it's complexity, but what about all the pre-existing tools? You can easily criticize the design of SOAP and various other members of the WS-* family, but you can't set aside the fact that there are a *MASSIVE* base of tools that allow instant interop with SOAP-based Web Services. Complicated yes, but not the tools, which I believe is the primary point people seem to be overlooking: If the complexity is hidden from the end user, why should the end user really give a damn what the underlying philosophy is all about?

    REST is fine for pub/sub. In fact, anything else is massive overkill. But pushing REST to be the end all, be all WS-API of the web is a mistake, because it doesn't solve every problem presented. At least not without being forced to reinvent the wheel, *even if* the resulting wheel can be more round.


    Thomas, you don't seem to care much about your data then, do you?

    The thing is, the SimpleDB RESTless API is doubly bad because not only does it misadvertise itself as RESTful, but it tunnels over GET rather than POST, which completely runs against the grain of the rest of the web. Using GET like this is *dangerous*.

    I spend much of my time writing code to talk to other systems that tunnel some kind of RPC mechanism over POST. Even though it feels dirty, I can tolerate that. RPC tunnelled over GET, on the other hand, is just plain wrong.


    @M. David Peterson: The complaint isn't against the SOAP interface, it's about how they've tunnelled it over GET and branded it as RESTful. Personally, I'd prefer to use the SOAP interface over the "RESTful" on they've provided. The fact is, the "RESTful" API's misbranded and poorly engineered. That's the beef.

    And nobody's pushing REST to be be-all-and-end-all of anything, and I'm not even sure how that comes into it. I wish that meme would go into a corner and die.


    To me, the saddest part is that outside of a core group of us techies, I'm not sure anyone really cares whether the interface is RESTful or not.


    Amen.


    @Mike: Of course they don't. but it's our duty as developers to care because we care about the systems we produce working properly and not wasting our clients' money because they don't.