From what I have seen so far, creating a custom ServerMessageDeliverer seems to be a more complicated solution. Actually, the correct solution seems to be to override CoapResource#getChild(String) so that it returns the resource you want to associate with this name. ServerMessageDeliverer more like a way to implement some kind of controller that delivers or distributes requests in a more complex environment.
For the question where the last part of the URI is a parameter, the solution might look like this:
public class UriParameterResource extends CoapResource { public UriParameterResource() { super("foo"); } @Override public void handleGET(CoapExchange exchange) { List<String> uriPath = exchange.getRequestOptions().getUriPath();
Regarding the answer from @Copernic, I personally think that this is not consistent with the idea of REST. Each part of the URI path must return its own resource associated with its parent, which makes it a tree structure for each definition, and not a flat list that simply checks the parts of the path as some parameter.
IMHO even an example of sensors can be resolved using CoapResource implementations, where a child variable resource can be dynamically resolved. Below is a snippet below, of course, this should depend on the real situation when the house and its rooms must be somehow registered.
public class HousesResource extends CoapResource { public HousesResource() { super("houses"); } @Override public void handleGET(CoapExchange exchange) { // could return a list of available houses exchange.respond(ResponseCode.NOT_IMPLEMENTED); } @Override public Resource getChild(String name) { Resource child = super.getChild(name); if (child == null) { child = new HouseResource(name); add(child); } return child; } class HouseResource extends CoapResource { public HouseResource(String name) { super(name); add(new RoomsResource()); } @Override public void handleGET(CoapExchange exchange) { exchange.respond(ResponseCode.NOT_IMPLEMENTED); } } class RoomsResource extends CoapResource { public RoomsResource() { super("rooms"); } @Override public void handleGET(CoapExchange exchange) { // could return a list of available rooms exchange.respond(ResponseCode.NOT_IMPLEMENTED); } @Override public Resource getChild(String name) { Resource child = super.getChild(name); if (child == null) { child = new RoomResource(name); add(child); } return child; } } class RoomResource extends CoapResource { public RoomResource(String roomName) { super(roomName); add(new SensorsResource()); } @Override public void handleGET(CoapExchange exchange) { // could return a summary board about the room exchange.respond(ResponseCode.NOT_IMPLEMENTED); } } class SensorsResource extends CoapResource { public SensorsResource() { super("sensors"); add(new TemperatureResource()); } @Override public void handleGET(CoapExchange exchange) { // this could return a list of registered sensors exchange.respond(ResponseCode.NOT_IMPLEMENTED); } } class TemperatureResource extends CoapResource { public TemperatureResource() { super("temperature"); } @Override public void handleGET(CoapExchange exchange) { // as the structure is fixed we know that two levels up // there is the room, and four levels up there is the house String room = getParent().getParent().getName(); String house = getParent().getParent().getParent().getParent().getName(); exchange.respond("The temperature of the " + house + " in the " + room + " is : 25 degree"); } } }
In this example, resources are dynamically created if they did not exist before. It can also be exchanged using some search or registration mechanism (for example, a house is registered through PUT or PUSH).
Do not misunderstand me. The @Copernic solution seems to work and is probably a suitable solution for some scenarios (for example, each house has its own server and requests should be redirected), but for a fairly simple scenario it seems to me that this is not the way to go.