Modeling a "method" as a reflection resource violates REST style?

I am new to REST and may very well be pushing/crossing limits...

Say we have the typical Order example:

GET /Order/12345

Now I would like to publish a reflection resource to describe the "Order" type in terms of properties, methods, relationships.

GET /Reflection/Type/Order

Amongst other things, the reply could contain the URI for the representation of the reflection object of the method "foo"开发者_高级运维 of type "Order"

/Reflection/Type/Order/Method/foo

Next we could POST to that URI to use/call/post-to the method... If the method needed parameters, they would be passed in the body.

POST /Reflection/Type/Order/Method/foo

My reasoning:

• view the objects/concepts/things in the reflection layer as resources
• "Type", "Method" are nouns
• "foo" is an id <============ THIS MIGHT BE (OR IS) THE PROBLEM
• GET /Reflection/Type/Order/Method returns all Method representations of type "Order"
• GET/PUT/DELETE of the reflection layer objects still make perfect sense (idempotency, etc)

I am now leaning towards having a transaction queue and POST-ing a transaction there...

POST /TransactionQueue

The body will contain URI to the reflection resource representing the method foo (/Reflection/Method/foo), URI's to any object resources and normal values for non-object arguments.

QUESTION: Is this interpretation tolerable or does it violate the REST style in the worst possible way?

If the above is bogus, I would need some hints about a RESTful interface to publish:

• objects
• a reflection layer describing what properties/methods/relationships the exposed objects have
• a way to execute methods on the objects

Update: This about HATEOAS is very interesting...

Update: Look for RestEasy powerpoint by Peter Lacey of Burton Group

Update: Podcast http://www.udidahan.com/2008/03/16/podcast-rest-messaging-enterprise-solutions/

Update: book "Restful web services cookbook"

Update: book "Rest in practice"

This design won't lead to a very Restful system, it does not provide a uniform interface. In fact the stated requirement for "a way to execute methods on the objects" itself violates the notion of providing the client a uniform interface. You will of course be executing methods on objects behind the scenes, but pushing that model into the interaction layer violates the principle of providing clients a uniform interface.

All interaction should be in the form of GET, PUT, DELETE and POST against resources.

Hypertext is very important, as you have discovered, for informing the client of the appropriate subsequent choices after they have fetched a resource. There are a number of formats that might help you describe the types of relationships you are looking for, try RDFa for example.

Slowly getting there with HATEOAS:

• The Web is already RESTful.
• You only need one entry point URL
• IMHO URL's should correspond to resources/nouns. It's perfectly fine to have cool, opaque, useless-looking URL's which don't reveal any semantics. Moreover the client is forced to interpret the semantics of hyperlinks by their formal description instead of interpreting the URL itself.
• The semantics of hyperlinks is expressed with (standardized) formal descriptions. This is the language of hyperlinks and it's the only language that the client needs to know. Examples are RDF, Atom etc.
• Just view the client as a specialized browser that only knows (custom) link types and media types.
• The client can not do anything other than following links it has received within responses. It does not construct any URLs by itself.

Particularly enlightening:

• Approaching pure REST: Learning to love HATEOAS
• Roy Fielding: REST APIs must be hypertext-driven, the comments!
• "How to get a cup of coffee" and the comments on it