restfulobjects / restfulobjects-spec

The Restful Objects specification defines a set of RESTful resources, and corresponding JSON representations, for accessing and manipulating a domain object model.
http://restfulobjects.org
73 stars 10 forks source link

Explain how implementations might deal with overloaded actions. #4

Closed danhaywood closed 10 years ago

danhaywood commented 11 years ago

ver: 1.0.0

ref: http://restfulobjects.codeplex.com/workitem/42

I don't think that the spec itself needs changing, but it probably needs a new section clarifying how implementations should handle this.

Which is...

The format of the action identifier within the URL isn't defined by the spec, so any unique identifier can be used. In the case of an overloaded action, the implementation can merely needs to take appropriate steps to make that action identifier unique. (It probably should document this for anyone who wants to invoke URLs using templated actions).

For example, if there is:

AppendComment(String x)

and

AppendComment(String x, int y)

then the implementation could use the number of arguments as a distinguisher, eg "AppendComment1" and "AppendComment2". This simple encoding ought to suffice in the vast majority of cases.

If the implementation happens to have overloads with the same number of arguments, eg:

AppendComment(String x)

and

AppendComment(int y)

then the implementation will need another means to encode a unique ID. In the Java language spec this is formalized so that, for example I = int, and S = string (see http://dev.kanngard.net/Permalinks/ID_20050509144235.html for full example).

Thus, the above could be "AppendComment_S" and AppendComment_I" respectively.

Where things will be the most complicated is when the overloading is through an entity type, eg:

AppendComment(CommentType t, String x)

and

AppendComment(PriorityType t, String x)

In this case the unique identifier could use the type identifier of the referenced types, eg "AppendComment_CTP_S" and "AppendComment_PTY_S".

danhaywood commented 10 years ago

I think what's in the spec 1.1 now is fine (not sure if I added anything new, but it reads ok to me).