2013-12-20, 04:16 AM
lukemb3 Wrote:I don't really pay attention to .net flavors of Rest. To be honest I really have no idea what that means. I know that a major principle is that each interesting resource is available using a unique identifier, which in an http-based api means the Uri. Whether that's /Movies/Unwatched, or /Movies?IsWatched=false is largely a matter of taste. Either way you're pulling down a resource which is unwatched movies.
In any event, it's fine, I can work around it. But my own advice is that it sounds like you're exposing your domain implementation beyond your interface (the api). At least I get that impression based on you're saying that you built it so that clients construct the same objects as you do in your own domain. It just means you're going to feel some pain if you ever have to change anything.
Not talking a .Net flavor.... just discussions on this topic with .Net developers.... REST is not .Net specific and does not have specific requirements.... but there are best practices that are recommended for using a REST architecture.....that is what I was referencing. The REST architecture supports Posting including posting of JSON objects so the practice is not a nitch practice within .Net or and is valid within any system that implements the usage of that ability.
That is why I supply methods to get a default object..... having that ability....the client should be able to check their local object to see if there are differences (i.e. on initial startup, once a day, week etc.) or instantiate their local object on startup by pulling the default object.
With a querystring.... if the host adds add a required parameter that the client isn't aware of you are in the same boat.... the client would have an issue.... correct? I am not sure how the client becomes aware of a required parameter when only available via querystring.
To me... a querystring argument is merely a property from an object..... only not contained within an object.... so even when only using querystrings you are extending the server (interface API) to clients... just in an unstructured manner.
That said.... I can probably extend the objects to be provided via querystring. I'll keep you posted.
Even with that you will only know what you submitted..... not what was all involved in the processing of the action within the host since you are only providing certain properties of the object that is used within server processing.
To manage this issue I created a method tonight which I will implement on the posts that will write the value of submitted object to the web.log on the server when debug level logging is set. Below is an example:
Code:
2013-12-19 22:40:08.391 [INFO][18] Search Object Properties received:
2013-12-19 22:40:08.392 [INFO][18]
searchVersion: 4.1
searchName: Testing
autoShowSearch: False
autoRecordSearch: False
searchTitle: True
searchSubTitle: False
searchDescription: False
matchTitle: False
matchSubTitle: False
matchDescription: False
startTitle: False
startSubTitle: False
startDescription: False
searchTreeviewSortOrder:
searchLengthMin: -2147483648
searchLengthMax: 2147483647
searchGenres:
searchPhrase: Letterman
searchCaseSensitive: False
searchChannels:
2
502
searchStartDate:
searchStartTime:
searchEndDate:
searchEndTime:
searchDays:
True
True
True
True
True
True
True
Intel Core i7 @ 4.00GHz Skylake 14nm
ASUSTeK COMPUTER INC. Z170-DELUXE
Windows 10 Pro x64
PVR Software: NPVR 5.1.1
SiliconDust HDHomeRun HDHR5-4US Connect Quatro 4 Channel Tuner
Roku Ultra
2 PCH A-100's
ASUSTeK COMPUTER INC. Z170-DELUXE
Windows 10 Pro x64
PVR Software: NPVR 5.1.1
SiliconDust HDHomeRun HDHR5-4US Connect Quatro 4 Channel Tuner
Roku Ultra
2 PCH A-100's
