Fundamentals of API design

• interface that is an easy-to-understand and easy-to-use representation of what users can do with a device, without bothering them with irrelevant inner-working concerns.

• Always try to avoid the provider perspective when you design your API, try to make the API easy to use for the consumer
• Consumers don’t care about your software architecture choices. What they care about is seeing all the information they need easily

• Always Choose property’s type , that’s common in many different programming languages like number,string,boolean.
• A Parameter should Must Provide the needed Datat but nothing more, it should not include data that is execlusively handled by the backend
• The HTTP method POST is the default method to use when no other method fts the use case.
• to be RESTful architecture needs to conform the following six constraints
  • Client/server separation —There must be a clear separation of concerns when components like a mobile application and its API server work and communicate together.
  • Statelessness —All information needed to execute a request is contained within the request itself. No client context is stored on the server in a session between requests.
  • Cacheability —A response to a request must indicate if it can be stored (so a client can reuse it instead of making the same call again), and for how long
  • Layered system —When a client interacts with a server, it is only aware of the server and not of the infrastructure that hides behind it. The client only sees one layer of the system.
  • Code on demand —A server can transfer executable code to the client (JavaScript, for example). This constraint is optional.
  • Uniform interface —All interactions must be guided by the concept of identifed resources that are manipulated through representations of resource states and standard methods. Interactions must also provide all metadata required to under- stand the representations and know what can be done with those resources. This is the most fundamental constraint of REST, and it is the origin of the Represen- tational State Transfer name. Indeed, using a REST interface consists of transfer- ring representations of a resource’s states.
• If a parameter contains data that cannot be provided by consumers, you missed something

Designing straightforward representations:

• Recommended to not use more than 3 words to craft names
• Basically chose some names than can be understood by customers easily
• choosing appropriate data formats when designing an api as important as choosing appropriates names in order to provide a strightforward api design.
• always choose ready to use data