« Times Reader 2.0 | Main | Information Engineering »

Wednesday, May 20, 2009


Feed You can follow this conversation by subscribing to the comment feed for this post.

Scott Wheeler

I'd add:

- Tools for systematic testing

- Tools for documenting the APIs

- Ideally WADL support (not seen much uptake yet, but I like the idea)

Cesare Pautasso

- What kind of WADL support? Not sure Erik would like code generation :-)

What about:

- High level exception handling (to manage HTTP status codes more declaratively*)
- Higher level conneg
- HTTPS out of the box (no special Java VM Configuration to make it work)
- URL Extraction (to find links embedded in arbitrary content)



@scott @cesare: it seems to me that WADL was a nice thought experiment but was largely rejected by the community. which of course doesn't mean it couldn't be supported, but it might not be something many people would use.

wrt tool: yes, tools are good. testing is something i'd see a bit outside of the actual language toolbox for development, but it definitely should be part of each developer's toolbox. but what kind of "APIs" would you like to document, scott? according to REST, they all have a uniform interface, so most of the "documentation" is in the media types and in the interactions. but yes, there should be some support for systematically documenting the grid of HTTP methods and "URI templates".

HTTPS: definitely something i should have mentioned, HTTPS should be supported as part of the toolbox, and it should support the largest possible set of encryption methods. authentication (which i did mention) is useful and often required, but without HTTPS, authentication often i only one part of security. another thing one might add to HTTPS is the support of client-side certificates, which are optional in HTTPS, but very useful in scenarios where all participants can agree on a set of certification authorities they are going to trust.


i've been working on a similar list lately. mine is for talks to the .NET crowd, but it also applies to other communities. i break things out as follows:

- a URI dispatcher (able to parse URIs and route based on rules)
- a resource handler (able to accept routing, map HTTP methods to executable code, able to understand HTTP Headers as needed)
- a transformation library (able to transform input and output data into appropriate representations [XHTML, JSON, Atom, SVG, PDF, etc.)
- a full-featured HTTP client library (able to handle requests/responses to other HTTP sources like remote servers, etc.)
- a caching library (able to understand HTTP Headers, honor support outbound caching details and honor caching of remote server responses)
- an authentication library (support for Basic/Digest as well as HTTPS details. other auth formats optional)

FWIW, i've been creating this kind of library/framework for the .NET space for the last year or so (http://exyus.com)

The comments to this entry are closed.