What is a web service?
A web service is an interface through which applications exchange data or invoke functions over a network. A website is designed primarily for people to read and use; a web service exposes a contract intended for software clients. The same product can provide both. Many services use HTTP and JSON, but the term includes other protocols and data formats.
How a request and response work
A client sends a request to a defined endpoint with a method, parameters and, when required, credentials. The service validates the request, performs its operation and returns a response. For HTTP APIs, status codes distinguish broad outcomes: a successful response, a client-side problem such as invalid input, or a server-side failure. The response body usually provides more detail in a documented format.
A clear contract describes paths, methods, fields, types, authentication, rate limits and error conditions. This contract lets clients be developed independently. Versioning matters because changing a field or interpretation can break existing applications even if the endpoint address remains the same. Maintain backward compatibility where promised and publish deprecation periods.
Common interface styles
REST is an architectural style, not a single wire format. HTTP APIs described as RESTful commonly represent resources with URLs and use methods such as GET for reading and POST or PUT for changes. A GET should not create a lasting state change; clients and intermediaries may repeat or cache it. SOAP uses structured XML messages and formal service descriptions in many enterprise systems.
GraphQL lets clients request a defined selection of fields through a schema, often over HTTP. It can reduce unnecessary data transfer, but adds complexity around query cost, authorisation and caching. Webhooks reverse the usual polling pattern: one service calls a registered endpoint when an event occurs. Webhooks need authentication of the sender, retry handling and protection against duplicate delivery. None of these approaches is universally best.
Security and privacy
Use HTTPS to protect data in transit and verify the server certificate. Authenticate callers with an appropriate credential scheme and authorise each operation and object separately. A valid token proves only what its scope allows; it does not make arbitrary input safe. Validate request size and types, avoid exposing private data in errors, and set limits against abuse.
Secrets should not appear in public URLs, client-side source code or logs. Rotate exposed credentials, restrict their scope and use separate production and test credentials. For APIs accepting a callback URL, validate destinations to prevent requests to internal networks. Document what personal data is returned and retain only what is needed.
Reliability and performance
Networks fail, so clients need timeouts, bounded retries and clear handling of partial failures. Retry a read when safe; retrying a payment or another mutation requires an idempotency design to avoid duplicates. Pagination limits large result sets. Caching can reduce load for stable public data, while rapidly changing or private responses need careful cache policy.
Operators should measure latency, error rates and availability from the actual client path. A server returning HTTP 200 can still return incomplete or unusable data, so monitor expected business outcomes too. Rate limits protect a service but should be communicated in a predictable way. Provide a status page or support channel for incidents when the service is important to users.
Choosing or building a service
Start with the user’s task and the data contract, then choose an interface style that clients can implement and the team can maintain. Test normal responses, malformed input, expired credentials, permissions, pagination and timeouts. Keep examples current and show concrete errors. When integrating a third-party service, read its usage limits, data policy and change notices; a convenient endpoint is still a dependency that can fail.