Scribd Logo
Upload

Welcome to Scribd!

  • 107 views

    Api Microservice PDF

    Uploaded by

    garibmanush
    Cloud-native applications are collections of small, independent, loosely coupled services that are designed to provide consistent development and automated management across private, public, and hybrid clouds. Organizations adopt cloud computing to increase scalability and availability of apps through self-service provisioning of resources and automating the application life cycle. Cloud-native development is an approach to building and updating apps quickly while improving quality and reducing risk, allowing apps to be responsive, scalable, and fault-tolerant anywhere.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Api Microservice PDF

    Uploaded by

    garibmanush
    107 views3 pages
    Cloud-native applications are collections of small, independent, loosely coupled services that are designed to provide consistent development and automated management across private, public, and hybrid clouds. Organizations adopt cloud computing to increase scalability and availability of apps through self-service provisioning of resources and automating the application life cycle. Cloud-native development is an approach to building and updating apps quickly while improving quality and reducing risk, allowing apps to be responsive, scalable, and fault-tolerant anywhere.

    Original Title

    API MICROSERVICE.pdf

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Cloud-native applications are collections of small, independent, loosely coupled services that are designed to provide consistent development and automated management across private, public, and hybrid clouds. Organizations adopt cloud computing to increase scalability and availability of apps through self-service provisioning of resources and automating the application life cycle. Cloud-native development is an approach to building and updating apps quickly while improving quality and reducing risk, allowing apps to be responsive, scalable, and fault-tolerant anywhere.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    107 views3 pages

    Api Microservice PDF

    Uploaded by

    garibmanush
    Cloud-native applications are collections of small, independent, loosely coupled services that are designed to provide consistent development and automated management across private, public, and hybrid clouds. Organizations adopt cloud computing to increase scalability and availability of apps through self-service provisioning of resources and automating the application life cycle. Cloud-native development is an approach to building and updating apps quickly while improving quality and reducing risk, allowing apps to be responsive, scalable, and fault-tolerant anywhere.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 3

    cloud-native applications

    Cloud-native applications are a collection of small, independent, and loosely coupled services.
    If an app is "cloud-native," it’s specifically designed to provide a consistent development and automated
    management experience across private, public, and hybrid clouds.

    Organizations adopt cloud computing to increase the scalability and availability of apps. These benefits are
    achieved through ​self-service ​and ​on-demand​ provisioning of resources, as well as ​automating ​the application
    life cycle from development to production.

    Cloud-native development is just that—an approach to building and updating apps quickly, while improving quality
    and reducing risk. More specifically, it’s a way to build and run responsive, scalable, and fault-tolerant apps
    anywhere—whether in public, private, or hybrid clouds.

    MICROSERVICE
    Microservice architectural style is an approach to developing application as
    a suite of small services, each running in its own process and communicating with each other using a
    communication protocol such as HTTP (and REST), RPC (Remote Procedure Call) or AMQP (Advanced
    Message Queuing Protocol). These services are independently deployable and scalable.

    API
    ● a set of functions and procedures allowing the creation of applications that access the features or data of
    an operating system, application, or other service.

    ● An API is a set of definitions and protocols for building and integrating application software. API stands for
    application programming interface. APIs let your product or service communicate with other products and
    services without having to know how they're implemented.

    ● API is the acronym for Application Programming Interface, which is a software intermediary that allows two
    applications to talk to each other.

    There are many types of APIs. One of the most common types of APIs are Web APIs; these APIs, otherwise
    known as Web Services, provide an interface for web applications, or applications that need to connect to each
    other via the Internet to communicate. There are tens of thousands of public APIs that can be used to do
    everything from checking traffic and weather, to updating your social media status, or even to make payments.

    REST
    Representational State Transfer (REST) is a software architectural style that defines a set of constraints to be
    used for creating Web services. Web services that conform to the REST architectural style,
    called RESTful Web services (RWS), provide interoperability between computer systems on the Internet. RESTful
    Web services allow the requesting systems to access and manipulate textual representations(state) of Web
    resources by using a uniform and predefined set of stateless operations.
    RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE
    data. suitable for internet usage.

    The 6 constraints are:

    Client-server​: The client and server are independent. They interact with each other through requests that the
    client initiates. The server listens for requests and answers them.

    Stateless​: The server doesn’t store any state about previous requests. For example, it doesn’t track if a client
    already requested a resource before. It also doesn’t track which resources were requested by a client.

    Cacheable​: The server includes a version number in its messages. The client can use this to decide whether it
    should request a resource again or use the cached data.

    Uniform interface​: The interface is decoupled from the implementation.

    There are four sub-constraints:

    Identification of resources:​ each resource must be uniquely identifiable via a URI (Uniform Resource
    Identifier).

    Manipulation of resources through representations:​ a client can’t interact directly with a server’s
    resource. For example, you can’t run a SQL query directly from the client against a server’s database. We
    have to use a representation and neutral data format. When a client wants to update a resource, it has to
    take the following steps:
    1. Request a representation of the resource.
    2. Update the representation with new data.
    3. Send the representation of the resource to the server.
    Self-descriptive messages: ​Each message (request or response) must include enough information so
    the receiver can understand it. A message requires a media type (for example “application/json”) that tells
    the receiver how to parse the message.
    Hypermedia as the engine of application state (HATEOAS):​ You should be able to discover other areas
    of the API similar to how a user browses a website. A response from the API should include links to other
    parts of the API. This way, you can figure out how the API works without referring to external
    documentation.

    Layered system:​ REST allows a layered system. You could deploy the API on one server and the data on
    another server. You could add additional layers like a load-balancer in between the client and server. The client
    can’t tell whether it’s communicating with an intermediate or end server. Extra layers should not affect
    communications between the client and the server.

    Code on demand (optional)​: This is an optional constraint. The server usually sends a static representation in
    JSON or XML. The server can optionally include executable code to a client. An example is a Java applet or
    JavaScript.
    Web service vs web application and Flask

    ● Web Services ​can be used to transfer data between ​Web Applications.​ Web Services can be accessed
    from any language or platform. A Web Application is meant for humans to read, while a Web Service is
    meant for computers to read.

    ● Flask​ is a lightweight WSGI web application framework. It is designed to make getting started quick and
    easy, with the ability to scale up to complex applications. It began as a simple wrapper around Werkzeug
    and Jinja and has become one of the most popular Python web application frameworks.

    YAML JSON XML : Data Serialisation language

    Serialisation is the process of translating data structures or object state into a format that can be stored (for
    example, in a file or a memory buffer) or transmitted (for example, across a network connection link) and
    reconstructed later.

    YAML is used to represent data-structure and vastly use for configuration file format. sometimes it is called
    superset of JSON.

    YAML supported structures are:

    - list
    - dictionary
    More complicated data structures are possible, such as lists of dictionaries, dictionaries whose values are lists or
    a mix of both:

    You might also like