CXF REST Conventions

, Dec 4, 2006

Dan Diephouse:

The latest code in CXF’s SVN takes a cue from the Ruby community and knows how to turn CRUD operations into resources automatically.


  • Selection: Collection<People> getPeople() is mapped to an HTTP GET on /people
  • Person getPerson(id) is mapped to an HTTP GET on /people/{id}.
  • void addPerson(Person person) is mapped to an HTTP POST on /people.
  • void updatePerson(long id, Person person) is mapped to an HTTP PUT on /people/{id}.
  • void deletePerson(long id) is mapped to an HTTP DELETE on /people/{id}

Very neat.

On December 4, 2006 4:55 PM, Mark Baker said:

Hmm, but why the “People” qualifier on all the verbs? What value does that add? Why not just “Collection get()”?

On December 4, 2006 5:00 PM, Stefan Tilkov said:

One reason would be to have a single class “serve” multiple resources. Or would this be weird? I’m not sure. Is it your opinion that the implementation structure should match the “external resource view” 1:1?

On December 4, 2006 5:35 PM, Mark Baker said:

Not necessarily, but I don’t see why it doesn’t in this case.

On December 5, 2006 9:38 PM, Dan Diephouse said:

Mark: good question. As Stefan outlined there are often classes which serve out mulitiple different types of things.

If you are only serving out one type of resource - i.e. People - it is redundant and get/update/remove/delete are sufficient. It is also more RESTful that way. However, the way I implemented it seemed most natural for a lot of Java developers. Or at least to me. :-) I suppose it would be a good idea to support multiple conventions both the one you mentioned and the original one I did.

I would probably also want to support getAll() as I think people will find get() ugly from a Java POV. People are used to getters where they have getFoo(). I think they’ll tacitly feel that get() alone is ugly and want something like getPeople/getAll instead.