- Choose what the team is familiar with.
- Don’t be cool — play in your free time.
- Choose the right tool for the job.
- Prefer principles of good software design over the latest hype.
- Don’t overload the number of languages.
- Educate yourself & the team on foundations of computer science.
I just read this post in DZone (this is the original) related to “API Development: Design-First or Code-First?” and I am not agree with the second phrase in “The design-first approach advocates for designing the API’s contract first before writing any code. This is a relatively new approach“.
People talks about API’s like if they were born recently but we integrate systems since long time ago, so I think we should design API’s for those integrations, don’t you think? You can ‘google’ for “WSDL-first” or “Contract-First” and you will get a lot of results about “design-first” when we built SOAP API’s long time ago.
I personally prefer “Design-first” for some reasons:
- It’s not only designing any API, it’s about your “Company API Strategy“. It’s about how will people think about the way you show your “business”.
- Server and client side are able to build at the same time; it’s not implementation aware.
- If you adopt “Code-first”, you have to be aware about the name conventions for the classes you declare. For instance, if you use the “DTO” suffix convention, may be this “DTO” suffix will be exposed in your API and it sucks.
En muchas ocasiones nos hemos visto en la necesidad de incorporar valores que se corresponden con un enumerado, como por ejemplo, diferenciación de tipos, estados,… Lo que se suele hacer es crear un enumerado en Java y posteriormente referenciarlo en la clase que lo necesite incorporando la anotación