|
I am finding myself building up a whole bunch of JSON calls all through my application, which are basically actions spread across various controllers. I am considering creating a JSON Controller to keep all the JSON actions in one controller, so instead of; I would call Might this have ramifications that I haven't considered? Can anyone think of any compelling reasons not to do this? |
|||
|
|
|
Rule 1. Cool URI's Never Change. http://www.w3.org/Provider/Style/URI Do NOT set your resource paths based on programming "optimizations" like this. Design your paths correctly irrespective of coding considerations. The path lives forever. Your code will come and go. Having the data type ("JSON" in your case) part of the path is frowned upon by some. They argue that the response type should not be part of the RESTful path to the object. They argue that the response type should be encoded in a header (Accepts, specifically) and the path should be unchanged. You can, for example, do things like this to achieve the same goal: unchanging URI with encoding not in the path. /Products/?response=JSON I don't totally agree with their logic. But, what's important is that programming language considerations do not drive path design for web services requests. I think that /Products.json is not bad RESTful design. I've used the /path/to/json/resource technique in a couple of different forms. The thing you need to be absolutely clear on is rule #1: Cool URI's don't change because of programming language or toolset considerations. |
|||
|
|
