Considerations when designing a web service from scratch

IamtheWalrus

I have been asked in interviews that if I was to design an API, like a web service, what things would I need to consider. I usually talk about the number of users, whether I'd use Soap or Rest. If it was connected to a DB. I usually mention that'd I'd wire it in with Spring Dependency injection and Spring transactions. The interviewer usually looks at me blankly.

What are the considerations?

Talisman

Here's a starting point ...

Ease of Use - An API should be simple to use and be well documented. Provide language-specific libraries to interface with the service.

Security - Always use SSL for access. Authentication mechanisms: Web tokens, Oauth etc.

Versioning - Incorporate a version number into the URL e.g. https://my.api.com/api/v1. This makes it easier to make new versions with breaking changes without pissing off existing users of the system.

Flexibility: Don't assume that everyone wants to use the same data format. Ideally the API should be able to return data in any specified format e.g. JSON, XML, YAML

Error handling: Use HTTP status codes and helpful error messages.

Aswerty

The only sensible response to a question like that is to ask them questions so that you have more information to work with. If they're being purposefully vague and want you to answer without further info then they're idiots. But even if they are idiots and you still have to answer, you might say hypothetically if there is such a requirement I might handle it this way or that way depending on the trade-offs.

The main thing that would worry me about your response is that you're giving them answers that boil down to "I'd use technology A or technology B". The question was around design and you should be able to answer without having to resort to specific tech. Most things can be built with any number of underlying technologies but the real engineering work is understanding, at a technologically agnostic level, what needs to be in place. Most tech stacks these days are versatile and any number of things will get the job done.

colm_c

It's a design question more than implementation details.

You should respond with general best practices around:
- security
- multiple data formats
- capacity
- CRUD vs actions
- REST vs soap
- documentation
- test strategies
- etc

As well as previous posters - ask questions about the business logic and use cases required.

colm_c

It's a design question more than implementation details.

You should respond with general best practices around:
- security
- multiple data formats
- capacity
- CRUD vs actions
- REST vs soap
- documentation
- test strategies
- etc

As well as previous posters - ask questions about the business logic and use cases required.

jmcc

As above but with a Scalability factor. How would it scale? Would it scale horizontally (processes spread across multiple servers) or vertically (more processes on a single server with more RAM and CPU power)?

But you definitely need to ask questions before suggesting all sorts of possible answers.

Regards...jmcc

Talisman

jmcc wrote: »

As above but with a Scalability factor. How would it scale? Would it scale horizontally (processes spread across multiple servers) or vertically (more processes on a single server with more RAM and CPU power)?

You're then straying away from design and getting into hardware and implementation.

But you definitely need to ask questions before suggesting all sorts of possible answers.

No you don't. There are basic best practices that developers should know when they are asked to design a web service API, these hold true no matter what the situation.

It should be possible for an interview candidate to begin answering the question before asking any questions - cover the basics and if they want to get into specifics then more information is required.

IamtheWalrus

Talisman wrote: »

You're then straying away from design and getting into hardware and implementation.

No you don't. There are basic best practices that developers should know when they are asked to design a web service API, these hold true no matter what the situation.

It should be possible for an interview candidate to begin answering the question before asking any questions - cover the basics and if they want to get into specifics then more information is required.

Can you help me out with said basics?

14ned

IamtheWalrus wrote: »

I have been asked in interviews that if I was to design an API, like a web service, what things would I need to consider. I usually talk about the number of users, whether I'd use Soap or Rest. If it was connected to a DB. I usually mention that'd I'd wire it in with Spring Dependency injection and Spring transactions. The interviewer usually looks at me blankly.

What are the considerations?

Tell them you'd implement the entire thing using the C preprocessor.

When they've stopped laughing, tell them you're serious and you're basing your answer on https://accu.org/index.php/journals/1926.

If that doesn't get you into the next stage of interviews, I'd be very surprised

Niall