Timeline for pattern to share objects between API and application
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 16, 2014 at 16:18 | comment | added | wasatz | And the same is of course true when working on your API project, try to imagine that you're writing a service that many 3rd party developers are going to use. Try not to think too much about your current application, but rather to keep your mind more on "what services am I providing" and assuming that everyone who is using your API (including yourself) are evil people who are trying to kill your server and make you delete your entire database. | |
| May 16, 2014 at 16:16 | comment | added | wasatz | Mainly, you should try to view your application and your API as two completely different and separate applications. You may be devloping them at the same time, and they might be in the same visual studio solution/eclipse project. But they are really two completely separate programs. When you're working in your application, try to "forget" that you are the one who has created the API and use it just as you would with a normal 3rd party API. That way you'll have a better chance of see how others will feel when using your API and correct the worst parts early on. | |
| May 16, 2014 at 16:14 | comment | added | wasatz | So you should validate your data transfer objects. But you should also make sure that the way you validate them doesn't accidentially introduce any dependencies on any other framework. And of course, as I said earlier, you really cannot be sure that your data transfer objects has been validated at all or that they have been validated by the same framework - so you must "validate twice". | |
| May 16, 2014 at 16:11 | comment | added | wasatz | I'm not saying that you shouldn't validate at the API level. To be honest, that's the single most important place to validate at. Validating in your app is just a "nice feature" to help your users to not make mistakes, validating your data transfer objects is for keeping malicious and erroneous data out. Since these are different use cases however, you might need to use different validation frameworks (you will use different validation frameworks if your app and your api isn't written in the same language) and you may validate slightly different things at each level (Cont. in next comment) | |
| May 16, 2014 at 14:07 | comment | added | Marc | Thank you for your explanations but I still find hard to understand something. I don't understand why the layer for data transfer doesn't have any validation? What if I forget some validations for my next mobile app? At least it wouldn't validate when I call the API instead of doing an exception in my database model. I'm not sure that I understand. | |
| May 16, 2014 at 14:02 | vote | accept | Marc | ||
| May 16, 2014 at 13:39 | review | First posts | |||
| May 16, 2014 at 14:13 | |||||
| May 16, 2014 at 13:21 | history | answered | wasatz | CC BY-SA 3.0 |