4 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

So instead of having a database as a data source for the API, I would make calls to the serial device

I assume that you have already resolved the access to the device data. Probably, you have abstracted the access with a DAO-like component.

The first approach would be to mock up the DAO. While the main component does real access to the device, the mocked one is just going to provide data from a document (or any other support).

Would be interesting to know if the DAO can retrieve the state of the device (plugged / unplugged). While the real DAO could answer yes/no, the mock could answer allways yes (or make the answer parametrizable by configuration).

Finally make them work altogether implementing a Gateway.

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

Following this approach, I suggest you to keep the API as agnostic to the environment as possible. Treat the device as if were a external service.

Adding flags to the request may fragment the code. What will lead you to non-functional if/else statements and polute the model with meaningless attributes.

Instead, use HTTP Headers. Implement your own headers (following some premises). Here a questionquestion related to the subject.

Example:

GET: /my/resource/id
Headers: [X-Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # No device

Due to the WebAPI is self hosted and mainly doing local requests, you have not to be worried about any proxy filtering the headers.

The header might also be the input you need to switch DAOs.

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few details about what's your app for. Security is not related to where my app runs at is more related to Who is going to have access? And what are they going be allowed to do?.

So instead of having a database as a data source for the API, I would make calls to the serial device

I assume that you have already resolved the access to the device data. Probably, you have abstracted the access with a DAO-like component.

The first approach would be to mock up the DAO. While the main component does real access to the device, the mocked one is just going to provide data from a document (or any other support).

Would be interesting to know if the DAO can retrieve the state of the device (plugged / unplugged). While the real DAO could answer yes/no, the mock could answer allways yes (or make the answer parametrizable by configuration).

Finally make them work altogether implementing a Gateway.

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

Following this approach, I suggest you to keep the API as agnostic to the environment as possible. Treat the device as if were a external service.

Adding flags to the request may fragment the code. What will lead you to non-functional if/else statements and polute the model with meaningless attributes.

Instead, use HTTP Headers. Implement your own headers (following some premises). Here a question related to the subject.

Example:

GET: /my/resource/id
Headers: [X-Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # No device

Due to the WebAPI is self hosted and mainly doing local requests, you have not to be worried about any proxy filtering the headers.

The header might also be the input you need to switch DAOs.

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few details about what's your app for. Security is not related to where my app runs at is more related to Who is going to have access? And what are they going be allowed to do?.

So instead of having a database as a data source for the API, I would make calls to the serial device

I assume that you have already resolved the access to the device data. Probably, you have abstracted the access with a DAO-like component.

The first approach would be to mock up the DAO. While the main component does real access to the device, the mocked one is just going to provide data from a document (or any other support).

Would be interesting to know if the DAO can retrieve the state of the device (plugged / unplugged). While the real DAO could answer yes/no, the mock could answer allways yes (or make the answer parametrizable by configuration).

Finally make them work altogether implementing a Gateway.

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

Following this approach, I suggest you to keep the API as agnostic to the environment as possible. Treat the device as if were a external service.

Adding flags to the request may fragment the code. What will lead you to non-functional if/else statements and polute the model with meaningless attributes.

Instead, use HTTP Headers. Implement your own headers (following some premises). Here a question related to the subject.

Example:

GET: /my/resource/id
Headers: [X-Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # No device

Due to the WebAPI is self hosted and mainly doing local requests, you have not to be worried about any proxy filtering the headers.

The header might also be the input you need to switch DAOs.

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few details about what's your app for. Security is not related to where my app runs at is more related to Who is going to have access? And what are they going be allowed to do?.

3 added 1124 characters in body
source | link

So instead of having a database as a data source for the API, I would make calls to the serial device

I assume that you have already resolved the access to the device data. Probably, you have abstracted the access with a DAO-like component.

The first approach would be to mock up the DAO. While the main component does real access to the device, the mocked one is just going to provide data from a document (or any other support).

Would be interesting to know if the DAO can retrieve the state of the device (plugged / unplugged). While the real DAO could answer yes/no, the mock could answer allways yes (or make the answer parametrizable by configuration).

Finally make them work altogether implementing a Gateway.

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

I would sayFollowing this approach, use Http Headers. The web API and Env are two different things. The first runs withinI suggest you to keep the second, that's it. Do your systemAPI as agnostic to the environment as possible. Treat the device as if were a external service.

Instructions relatedAdding flags to the envrequest may fragment the code. What will lead you to non-functional if/else statements and foreign systems, can be setted polute the model with httpmeaningless attributes.

Instead, use HTTP Headers. Implement your own headers (following some premises). For instanceHere a question related to the subject.

Example:

GET: /my/resource/id
Headers: [Serial[X-Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # the case to use theNo documentdevice

Due to the WebAPI is self hosted and mainly doing local requests, you have not to be worried about any proxy filtering the headers.

The header might also be the input you need to switch DAOs.

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few infodetails about what's your app for. In addition to this subject, securitySecurity is not related to where my app runs at is more related to whoWho is going to have access? And howwhat are they going be allowed to do?.

Even if it runs in each pc, like a O.S service, it may need users credentials to access to the file system, shared resources in the company network, etc.

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

I would say, use Http Headers. The web API and Env are two different things. The first runs within the second, that's it. Do your system as agnostic to the environment as possible.

Instructions related to the env and foreign systems, can be setted with http headers. For instance

GET: /my/resource/id
Headers: [Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # the case to use the document

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few info about what's your app for. In addition to this subject, security is not related to where my app runs at is more related to who is going to have access? And how are they going to?.

Even if it runs in each pc, like a O.S service, it may need users credentials to access to the file system, shared resources in the company network, etc.

So instead of having a database as a data source for the API, I would make calls to the serial device

I assume that you have already resolved the access to the device data. Probably, you have abstracted the access with a DAO-like component.

The first approach would be to mock up the DAO. While the main component does real access to the device, the mocked one is just going to provide data from a document (or any other support).

Would be interesting to know if the DAO can retrieve the state of the device (plugged / unplugged). While the real DAO could answer yes/no, the mock could answer allways yes (or make the answer parametrizable by configuration).

Finally make them work altogether implementing a Gateway.

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

Following this approach, I suggest you to keep the API as agnostic to the environment as possible. Treat the device as if were a external service.

Adding flags to the request may fragment the code. What will lead you to non-functional if/else statements and polute the model with meaningless attributes.

Instead, use HTTP Headers. Implement your own headers (following some premises). Here a question related to the subject.

Example:

GET: /my/resource/id
Headers: [X-Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # No device

Due to the WebAPI is self hosted and mainly doing local requests, you have not to be worried about any proxy filtering the headers.

The header might also be the input you need to switch DAOs.

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few details about what's your app for. Security is not related to where my app runs at is more related to Who is going to have access? And what are they going be allowed to do?.

2 added 26 characters in body
source | link

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

I would say, use Http Headers. The web API and Env are two different things. The first runs within the second, that's it. Do your system as agnostic to the environment as possible.

Instructions related to the env and foreign systems, can be setted aswith http headers. For instance

GET: /my/resource/id
Headers: [Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # the case to use the document

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few info about what's your app for. AlsoIn addition to this subject, security is not related to where my app runs at is more related to who is going to have access? And how are they going to?.

Even if it runs in each pc, like a O.S service, it may need users credentials to access to the file system, shared resources in the company network, etc.

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

I would say, use Http Headers. The web API and Env are two different things. The first runs within the second, that's it. Do your system as agnostic to the environment as possible.

Instructions related to the env and foreign systems, can be setted as http headers. For instance

GET: /my/resource/id
Headers: [Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # the case to use the document

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few info about what's your app for. Also security is not related to where my app runs at is more related to who is going to have access? And how are they going to?.

Even if it runs in each pc, like a O.S service, it may need users credentials to access to the file system, shared resources in the company network, etc.

So is it a good idea to have a flag in the http-request that specifies whether the api should get the data from the serial device or get testdata from say a document?

I would say, use Http Headers. The web API and Env are two different things. The first runs within the second, that's it. Do your system as agnostic to the environment as possible.

Instructions related to the env and foreign systems, can be setted with http headers. For instance

GET: /my/resource/id
Headers: [Serial-Device: xxxx, ...]

GET: /my/resource/id
Headers: [...] # the case to use the document

and the webapp would only call localhost, is there any need to think about security and authentication and the like?

Hard to say with so few info about what's your app for. In addition to this subject, security is not related to where my app runs at is more related to who is going to have access? And how are they going to?.

Even if it runs in each pc, like a O.S service, it may need users credentials to access to the file system, shared resources in the company network, etc.

1
source | link