4
Why allow the impossible?
I believe that I should be setting the Method property to string.Empty by default, and if the user doesn't supply the Method then the service won't execute (I.E. I'll check for that, and throw an exception if they didn't supply it).
Why? Why would you create a parameterless constructor if you know that it's going to blow up ...
2
In general, you can't. Have a search: search "cheat" on gamedev.stackexchange. This is not a language or runtime limitation. It is simply that the server is not in control of the client software, the user is.
Whatever happens on the client side software can either be imitated by another application, or the malicious users reverse engineer your app and make ...
2
I would not create a seperate model for this as it is essentially just a query. It seems like you are using a framework and you may be able to find a good way to express what you are looking for in that framework's docs. They often have a solution when working in their idiom.
I am from rails land. We tend to try to limit our controller code to quick ...
2
As you used the term endpoint in the subject of the question, I assume you are using (web) URI to define the location and identify of your (REST) resource.
Merging two methods into one based on the query parameters should not be the reason for your decisions. You should be defining your API based on your resources.
The methods that implement functionality ...
1
You came upon an operation for which RESTful design simply has not been made. It's a general problem with trying to make an API completely RESTful, and RESTful development should be taken with a grain of salt and pragmatism.
REST and RESTful approaches are good starting points to make your API more predictable. But as evolution goes, you are likely, just ...
Only top voted, non community-wiki answers of a minimum length are eligible
