Nie udało się skopiować do schowka. Proszę, spróbować ponownie po dostosowaniu uprawnień.
Skopiowane do schowka.
Unless you're a programmer, the distinction between SOAP and RESTful APIs can be confusing
Application Programming Interfaces (APIs) allow you to access information (data, measurements, etc.) or use third-party services (e.g. sending emails or text-messages) via the Internet. SOAP and RESTful are both APIs and aim to fulfill the same goals, but use different software architecture. Both allow you to build more feature-rich applications - in a shorter timeframe than building everything yourself. APIs are a viable option for minimizing development time.
Sometimes APIs are the only viable way to access certain services; sending SMS messages worldwide is a typical use-case. That being said, even if you could avoid using an API by simply implementing a scraper such as BeautifulSoup or PHP Scraper and access information from a website it is not recommended. An API should be your first choice before attempting to access the data using other ways. APIs change less frequently, are generally easier to integrate with and are more stable in long term.
What are APIs used for?
As the name “Application Programming Interface” suggests, allows you to interface with actions (functionality) within another program. In plain English, this means you can control actions such as creating, updating or deleting an entry within another program or database via the Internet or locally within your own intranet. These other programs are often called “services”, as they provide you with a service. Each functionality of a service is a so-called “API endpoint”.
While APIs vary in functionality and scope, there are two main types of APIs:
APIs which provide access to services such as email sending, posting updates, processing of images or video, etc. Also real-world actions like issuing/buying tickets or items are accessible via APIs.
The second type of API provides access to information such as data, statistics measurements, etc.
Besides the obvious use as data providers or external services, another advantage is the ability to break your application up into smaller parts. These parts can then interface with another via APIs. This allows you to split a part of your system and reuse it from any part of your system. Following this approach it is possible to increase the scalability and maintainability of your application.
This approach can be taken to extremes by developing and hosting so-called microservices. These microservices allow you to abstract any function of your application into its own service. Depending on the nature of your project/application this might be a viable option. Consulting with a solution architect can help you find this out. To avoid costly re-development, the approach should be defined from the get-go in your requirements document.
What is needed to work with an API?
To use an API and access the service or data provided by it, the software often requires you to obtain an access key to use a set of API endpoints. The key is usually provided after signing up for the service. Access keys can vary in permitted actions and scopes. Your developer needs the access key to integrate the API into your application.
Sometimes, services such as RapidAPI allow you to use one key for numerous APIs. And, if the API is not free to use, these services also process payments to API providers for you. From a business point of view, it makes sense to bundle APIs to ensure you are able to switch easily when one service is discontinued or doesn’t serve your needs. It also brings the benefit of easily testing APIs before committing.
For any API, checking the documentation to understand the defined interface is crucial. Often API provides open-source libraries to connect to their services. Sometimes you also find an API definition such as the OpenAPI standard. These allow you to use a standard library and configuration file to connect to any API providing such a configuration file
Apart from the different purposes of APIs mentioned above, there are also different technical implementations of APIs. In the following we will look more into these implementations:
What are SOAP APIs?
SOAP is short for “Simple Object Access Protocol” and appeared first in 1998. As the name suggests it was designed as a protocol to access objects (data) within a network. The standard relies heavily on the XML data-format. XML was originally intended to represent various types of documents, but it is also widely used to represent data structures thanks to SOAP APIs.
What are RESTful APIs?
The “REST” stands for “Representational State Transfer”. RESTful APIs are stateless APIs built on top of the HTTP protocol. This means the HTTP verbs “GET”, “PATCH”, “PUT”, “POST”, etc. are used to trigger actions in web-services. Each verb represents a particular action.
JSON is the data format of choice for RESTful APIs. This makes RESTful APIs more performant. HTTP-based Caching can be used by setting the correct response headers. These should always be set pro-actively to ensure there aren’t any unexpected side-effects such as data not being reloaded.
What are the advantages and disadvantages of the API types?
Fulfilling the same purpose, both APIs are naturally in competition. So what are the advantages and disadvantages of both?
SOAP API advantages:
SOAP APIs allow the use of different transport protocols through the Internet. It is built to work with both HTTP(S) and SMTP. This makes it suitable to work behind firewalls accessing the Internet.
Relying on XML, SOAP APIs out-of-the-box support internationalization using character sets defined in various XML namespaces. The only effort involved is ensuring the application behind the API can handle incoming unicode data.
RESTful APIs advantages:
XML is, by default, more verbose and requires more effort aggregating, transmitting and, finally, parsing. When using a SOAP API, this makes it slower compared to the same data transferred using JSON on a RESTful API. This gives RESTful APIs the upper hand on the performance side.
RESTful APIs are built on HTTP and allow for caching using the regular HTTP caching methods.
While both types have their advantages, in the end your decision needs to be made based on which one is provided to you.
As mentioned at the beginning, APIs provide viable shortcuts to reduce development time. If you integrate with APIs - be it SOAP or RESTful - you can shorten the time required to complete your project significantly, because you’re using code written and maintained by someone else. Maintenance is often not considered enough while planning a project.