I. API Definition. 2
II. API testing and Set-up of API Test environment. 10
2.1 What is API testing?. 10
2.2 When we use API Testing?. 10
2.2.1 We have three layer here: 10
2.3 Why is API testing important?. 11
2.4 Agile Software Development and Reduced Manual Regression Testing. 12
2.5 Set-up of API Test environment. 12
III. Types of Output of an API. 13
3.1 Any Type of Data. 13
3.2 Status (say Pass or Fail). 13
3.3 Calling of another API / Event. 14
IV. Test Cases for API Testing:. 14
V. Approach of API Testing:. 14
VI. Difference between API testing and Unit testing. 14
VII. What to test for in API testing. 15
VIII. Open source tool API Testing. 16
8.1 Postman. 16
8.2 Karate DSL. 19
8.3 Soap UI 19
8.4 HttpMaster Express. 20
8.5 Rest- Assured. 20
8.6 RestSharp. 20
8.7 Rest Console. 21
IX. Status Code. 21
9.1 1xx Informational responses. 21
9.2 2xx Success. 21
9.3 3xx Rirection. 22
9.4 4xx Client errors. 23
9.5 5xx Server errors. 24
API stands for Application Programming Interface. Hearing the word interface, many of us think of the user interface. In case of the API, however, we are dealing with the software-to-software interface that enables applications to talk to each other without any user knowledge or intervention. In its essence, API is a piece of software code, written in the series of XML messages. These messages define exactly which functions of the remote application will be leveraged. All in all, API can be defined as a set of rules that determine how one software communicates with another.
The huge benefit is that APIs can work with any common programming language, which makes them a convenient and easy to understand tool for the developers.
Currently the most common approach to delivering web APIs is REST, or Representational State Transfer. REST utilizes the same mechanisms that are applied to view regular web pages. Generally speaking, REST API allows you to reach data and functionality already available in one app and, through the programmatic API, make them accessible to other web and mobile applications. After that
API can return the data in the following formats:
XML – Extensible Markup Language
Data, delivered in any of the two formats can be easily accessed by developers and non-developer alike, since it can be smoothly transferred to spreadsheets and similar tools.
Advantages of API
1. Automation: with APIs, computers rather than people can manage the work. Through APIs, agencies can update work flows to make them quicker and more productive.
2. Application: because APIs can access the app components, the delivery of services and information is more flexible.
3. More scope: with an API an application layer can be created which can be used to distribute information and services to new audiences which can be personalized to create custom user experiences.
4. New data available: an API allows all of the information generated at the government level to be available to every citizen, not just a select few.
5. Efficiency: when access is provided to an API, the content generated can be published automatically and is available for every channel. It allows it to be shared and distributed more easily.
6. Integration: APIs allow content to be embedded from any site or application more easily. This guarantees more fluid information delivery and an integrated user experience.
7. Personalization: through APIs any user or company can customize the content and services that they use the most.
8. Adaptation: needs change over time and APIs help to anticipate changes. When working with this technology, data migration is supported better, and the information is reviewed more closely. In short, APIs make service provision more flexible.
What Do APIs Do?
A website uses a URL address to make a call to a server and pull up a webpage in a browser. APIs also facilitate calls to a server, but they execute it more simply. They connect the web, allowing developers, applications, and sites to tap into databases and services (or, assets)—much like open-source software. APIs do this by acting like a universal converter plug offering a standard set of instructions.
The Components of APIs: What You’re Sharing and Who You’re Sharing It With
1. All APIs begin with shared assets—they’re the currency of an API. They can be anything a company wants to share—whether that’s internally between teams, or externally with other developers: data points, pieces of code, software, or services that a company owns and sees value in sharing.
2. Next is the API, which acts like a gateway to the server. It provides a point of entry for your audience—developers who will use those assets to build their own software—but it also acts like a filter for those assets. You never want to open up your entire server and all of its contents to the outside world. APIs only reveal what you want them to reveal.
3. The immediate audience of an API is rarely an end user of an app; it’s typically developers creating software or an app around those assets. This is where assets take flight, yielding creative, new ways to implement data that previously, may or may not have had any real business value to its owner. It also lets developers use reusable software components so they’re not repeating work that’s already been done.
4. All of this results in apps that are connected to data and services, allowing these apps to provide richer, more intelligent experiences for users. API-powered apps are also compatible with more devices and operating systems, providing more seamless experiences.
5. In the end, the beneficiaries of these apps are the end users themselves. The apps enable end users tremendous flexibility to access multiple apps seamlessly between devices, use social profiles to interact with third-party apps, and more.
How do APIs work?
APIs have endless business opportunities. Here are a few ways to think about APIs and how they can work for you.
- APIs act as a doorway that people with the right key can get through. Want to give specific people—but not everyone—access to your assets? An API acts like a doorway to your server and database that those with an API key (or a paid subscription) can use to access whatever assets you choose to reveal. A key could give a user read access, write access, or both—it’s up to you.
- APIs let applications (and devices) seamlessly connect and communicate. An API can create a seamless flow of data between apps and devices in real time. This not only lets developers create apps for any format—a mobile app, a wearable, or a website—it allows apps to “talk to” one another. This is the heart of how APIs create rich user experiences in apps.
- APIs let you build one app off another app. Entire businesses and popular web applications like Hootsuite, Zapier, and IFTT (If This Then That) have been built solely on creative ways to leverage APIs. APIs allow you to write applications that use other applications as part of their core functionality. Not only can developers get access to reusable code and technology, they can leverage other technology for their own apps.
- APIs act like a “universal plug.” What if all of those people with keys to your door speak different languages? With an API, it doesn’t matter—everyone, no matter what machine, operating system, or mobile device they’re using—gets the same access. Think about those universal outlet plugs that let you use an appliance in any country’s socket. An API is a lot like that; it standardizes access.
- APIs act as a filter. Security is a big concern with APIs—after all, you’re giving outsiders access to your servers and all they contain—which is why they have to be carefully constructed. APIs should give controlled access to assets, with permissions and other measures that keep too much traffic—or malicious traffic—from bringing down your server. This is a very important API design consideration for industries that are heavily regulated, like healthcare and finance.
Type of API Webservice.
Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) are two answers to the same question: how to access Web services. The choice initially may seem easy, but at times it can be surprisingly difficult.
SOAP is a standards-based Web services access protocol that has been around for a while and enjoys all of the benefits of long-term use. Originally developed by Microsoft, SOAP really isn’t as simple as the acronym would suggest.
REST is the newcomer to the block. It seeks to fix the problems with SOAP and provide a truly simple method of accessing Web services. However, sometimes SOAP is actually easier to use; sometimes REST has problems of its own. Both techniques have issues to consider when deciding which protocol to use.
What is SOAP?
SOAP stands for Simple Object Access Protocol. It is a XML-based protocol for accessing web services..
SOAP is XML based protocol. It is platform independent and language independent. By using SOAP, you will be able to interact with other programming language applications.
A Quick Overview of SOAP
SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet such as the Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). These technologies fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet.
After an initial release, Microsoft submitted SOAP to the Internet Engineering Task Force (IETF) where it was standardized. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets
The XML used to make requests and receive responses in SOAP can become extremely complex. In some programming languages, you need to build those requests manually. However, other languages can use shortcuts that SOAP provides; that can help you reduce the effort required to create the request and to parse the response. In fact, when working with .NET languages, you never even see the XML.
Advantages of Soap Web Services
WS Security: SOAP defines its own security known as WS Security.
Language and Platform independent: SOAP web services can be written in any programming language and executed in any platform.
Disadvantages of Soap Web Services
Slow: SOAP uses XML format that must be parsed to be read. It defines many standards that must be followed while developing the SOAP applications. So it is slow and consumes more bandwidth and resource.
WSDL dependent: SOAP uses WSDL and doesn't have any other mechanism to discover the service.
What is REST?
REST stands for REpresentational State Transfer.
REST is an architectural style not a protocol.
Advantages of RESTful Web Services
Fast: RESTful Web Services are fast because there is no strict specification like SOAP. It consumes less bandwidth and resource.
Language and Platform independent: RESTful web services can be written in any programming language and executed in any platform.
Can use SOAP: RESTful web services can use SOAP web services as the implementation.
Permits different data format: RESTful web service permits different data format such as Plain Text, HTML, XML and JSON.
A Quick Overview of REST
REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations you must provide additional information in special ways, but most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.
The Difference between SOAP and REST APIs
II. API testing and Set-up API test environment
API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the business layer. During the API testing, the data is exchanged from XML or JSON through HTTP requests and responses. These are technology independent and will work with a variety of the programming languages and technologies.
is responsible for the delivery and formatting of information to the application layer for further processing or display and Gui testting word here . The presentation layer:
The presentation layer is the lowest layer at which application programmers consider data structure and presentation, instead of simply sending data in the form of datagrams or packets between hosts.
This is the main processing layer of the data before being displayed on the screen or processing the data before moving down the Data Access Layer to save the data to the database. This is where testing constraints, business requirements, calculations, processing requests, and return results for Presentation Layers. Business Layer:
This class performs operations related to storing and retrieving application data such as read, save, update databases. Database layer:
API Testing work in Business Layer.
2.3.1 Testing the Application Early and Without a User Interface
The later you find defects, the more expensive they are to fix. API testing engages testers early in development lifecycle. With API testing you can start testing your application early even without a UI. This helps to identify and fix issues early in development lifecycle which would otherwise be expensive to fix when identified during GUI testing. The advantage of API testing is that a lot of logic can be validated without being dependent upon the UI.
2.3.2 To Come up with an Awesome Test Automation Strategy and Reduce the Costs
If we understand the “Automation pyramid” we can come up with an effective automation strategy.
The test pyramid concept was developed by Mike Cohn and has been described in his book “Succeeding with Agile.” The base of the pyramid are the Unit Tests, these are the tests that are executed against the code. Unit tests are the least expensive to create; they are the fastest to execute and yield highest results. The 2nd layer are the API tests which are executed against the service layer. Finally, at the top of the pyramid are the UI tests that actually validates the application as a whole at presentation layer.
As we move up the pyramid, the cost involved in the creation and maintenance of tests, the test execution time, test fragility and test coverage keeps increasing. The automation pyramid preaches that you should do much more automated testing through unit tests and API tests than you should through GUI based testing. Agile’s success is hugely dependent on early feedback. During practices like continuous integration the amount of time the GUI regression tests take to provide feedback when new build is deployed is too long. UI tests are expensive to develop and maintain. A small change in UI can break the tests and lead to a lot of rework.
Several times the testers are forced to automate at UI layer. However, the tests end up being unreliable, expensive, slow and flaky. This is one of the reasons why many companies fail at efforts to implement an effective automation strategy.
According to a recent survey by VersionOne, 95% of the respondents said their organizations practice agile. Agile methodologies are no longer solely the domain of startups and small development shops. The main reasons for adopting agile over the traditional methodologies is to accelerate product delivery and to embrace the changes. Agile has also increased the frequency with which applications are released, which in turn has created an increased demand for new ways to quickly test them. Test automation has become a critical factor to maintain agility. So it is necessary for agile teams increase their level of API testing while decreasing their reliance on GUI testing. API testing is recommended for the vast majority of test automation efforts.
API automation can drastically reduce the pressure of regression testing from the QA team. By integrating the API automated tests to the build server, the QA team can provide a quick feedback on the health of the application as soon as it is deployed. This provides an early evaluation of its overall build strength before running GUI tests. API test automation requires you to code less and provides faster test results and better test coverage. APIs get stabilized early and are unlike to change frequently like the user interface. GUI tests can’t sufficiently verify functional paths and back-end APIs/services associated with multi-tier architectures. APIs are always the most stable interface to the system under test.
API testing is a unique form of software testing, and is particularly valuable for the businesses that embrace a continuous integration process. Building API tests during development of any software or service has far-reaching benefits across teams, all the way down to how your customer experiences the product. Making software that your target audience will love is essential to the success of your business and by having your APIs tested rigorously and regularly, you will ensure a reliable way of achieving it.
Api Testing is different than other testing types as GUI is not available, and yet you are required to setup initial environment that invokes API with required set of parameters and then finally examines the test result.
Hence, Setting up a testing environment for API testing seems a little complex.
Database and server should be configured as per the application requirements.
Once the installation is done, API Function should be called to check whether that API is working.
Output of API could be
Any type of data
Status (say Pass or Fail)
Call to another API function.
Let's look at an example of each of above Types
3.1 Any Type of Data
Example: There is an API function which should add two integer numbers.
Long add(int a, int b)
The numbers have to be given as input parameters. The output should be a summation of two integer numbers. This output needs to be verified with expected outcome.
Calling needs to be done such as
add (1234, 5656)
Exceptions have to be handled if the number is exceeding the integer limit.
3.2 Status (say Pass or Fail)
Consider the below API function -
They return any value such as True (in case of success) or false (In case of error) as an output.
A more accurate
Test Case would be, can call the functions in any of the script and later check for changes either in the database or the Application GUI.
3.3 Calling of another API / Event
In this case, we call one of the API function which in turn will call another function.
For example - First API function can be used for deleting a specified record in the table and this function in turn calls another function to REFRESH the database.
Test cases of API testing are based on
Return value based on input condition: it is relatively easy to test, as input can be defined and results can be authenticated
Does not return anything: When there is no return value, behavior of API on the system to be checked
Trigger some other API/event/interrupt: If output of an API triggers some event or interrupt, then those events and interrupt listeners should be tracked
Update data structure: Updating data structure will have some outcome or effect on the system, and that should be authenticated
Modify certain resources: If API call modifies some resources then it should be validated by accessing respective resources
Following points helps the user to do API Testing approach:
Understanding the functionality of the API program and clearly define the scope of the program
Apply testing techniques such as equivalence classes, boundary value analysis and error guessing and write test cases for the API
Input Parameters for the API need to be planned and defined appropriately
Execute the test cases and compare expected and actual results.
VI. Difference between API testing and Unit Testing
VII. What to test for in API Testing
API testing should cover atleast following testing methods apart from usual SDLC process
Discovery testing: The test group should manually execute the set of calls documented in the API like verifying that a specific resource exposed by the API can be listed, created and deleted as appropriate
Usability testing: This testing verifies whether the API is functional and user-friendly. And does API integrates well with another platform as well
Security testing: This testing includes what type of authentication is required and whether sensitive data is encrypted over HTTP or both
Automated testing: API testing should culminate in the creation of a set of scripts or a tool that can be used to execute the API regularly
Documentation: The test team has to make sure that the documentation is adequate and provides enough information to interact with the API. Documentation should be a part of the final deliverable
Example of some test case in API Testing an Application
Introduction about the application:
This project is to be used by different sizes of clients both very big and small. This is azure hosted solution that will integrate with their existing inventory system to provide a dashboard for marketing efforts. So inventory will have products and all that associated commerce data.
So essentially these are CRUD operations in form of HTTP requests.
Unit tests: So these are more free form and served as a template for rest of the suite, something in these lines
Can we add one product - HTTP POST
Can we add multiple products at the same time - HTTP POST
Can we delete a product by ID - HTTP POST (most folks don't use HTTP Delete)
Can we show a product by id- HTTP GET
Can we show multiple products by list of ids - HTTP GET
Can we update a product by ID and data - HTTP UPDATE (this created lots of bugs)
These are again simple cases once these are done, I went on to create edge test cases like
what happens when we add two products with the same id
update really doesn't do an update (is old value retained)
how many products can be added at once (system limits)
Can two exactly same products exist under different clients
Postman is a rest client that started off as a Chrome browser plugin but recently came out with native versions for both Mac and Windows.
Postman is a popular tool because it can easy download from Apps in Google Chrome
At a high level, you can use it to send Web methods as get/post/update/delete request to your web server and it gives you the response back. It allows you to set up all the headers and cookies your API expects, and then check the response when it comes back.
Can be used for both automated and exploratory testing
Can be run on Mac, Windows, Linux &Chrome Apps
Has a bunch of integrations like support for Swagger & RAML formats
Has Run, Test, Document and Monitoring Features
Doesn’t require learning a new language
POST MAN is the most popular API Test Tool.
Guide download and use Postman:
Open Google Chrome -> Web Store->Search Postman->Click setup:
1) Enter the API address and select the method (the action type) on the left of that field. The default method is GET but we will use POST in the example below.
2) Add authorization tokens/credentials according to the server side requirements. The different methods/protocols Postman supports are No Authentication, Basic Authentication (provide username and password only), Digest Authentication, OAuth 1.0, OAuth 2.0, Hawk Authentication and AWS Signature.
3) Enter headers in case they are required.
4) Enter a post body in case it is required. In this example we are creating a test that requires a JSON payload with relevant details.
5) If you wish to execute this API now, hit the ‘Send’ button, which is located to the right of the API request field. You can also click on the ‘Save’ button beside it to save that API request to your library.
8.2 Karate DSL
Karate allows you to create a test that can sequence calls to any kind of web-service and assert that the responses are as expected.
Build on top of Cucumber-JVM
Can run a test and generate reports like any standard Java project
A test can be written without any Java knowledge required
Tests are easy to write even for non-programmers
8.3 Soap UI
SoapUI is a headless functional testing tool from SmartBear software. It comes in two flavors: Free open source version and Pro Version. Since the free version is open-source, you can actually gain access to the full source code and modify as needed. The pro version is user-friendlier and has additional functionality including a form editor, an assertion wizard for XPath, and SQL query builder. The free version lets you:
Can easily create custom code using Groovy
Drag and Drop Test Creating
Can create complex scenarios
SoapUI’s Mock Service lets you mimic web services before they are implemented
8.4 HttpMaster Express
HttpMaster Express describes itself as a web development and test tool to automate testing of websites and services. It can be used to test RESTful web services and API applications. HttpMaster also allows you to and monitor API responses.
HttpsMaster project offers global options to customize your API request
Parameter capabilities enable you to include dynamic data with your request
You can use request chaining to leverage request items to include some data from the previous request with the next request
8.5 Rest- Assured
Rest-Assured is an open-source Java Domain-specific language (DSL) that makes testing REST service simple. It simplifies things by eliminating the need to use boiler-plate code to test and validate complex responses. It also supports XML and JSON Request/Responses.
Removes need to create boilerplate code required to interact with a rest service
Support BDD Given/When/Then syntax
Integrated seamlessly with Java projects
RestSharp is a simple REST and HTTP API Client for .NET
Supports .NET 3.5+, Silverlight 5, Windows Phone 8, Mono, MonoTouch, Mono for Android
Easy installation using Nuget for most .NET flavors
GET, POST, PUT, PATCH, HEAD, OPTIONS, DELETE supported
8.7 Rest Console
HTTP Client and Request Visualizer and Constructor tool, helps developers build, debug and test RESTful APIs. Rest Console is an HTTP Request Visualizer and Constructor tool, helps developers build, debug and test RESTful APIs.
Easy query parameters creation
Authentication support: Plain, Basic, OAuth + Custom
101 Switching Protocols
The requester has asked the server to switch protocols and the server has agreed to do so
102 Processing (
WebDAV; RFC 2518)
A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet. This prevents the client from timing out and assuming the request was lost.
103 Early Hints (
Used to return some response headers before file HTTP message
9.2 2xx Success
Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.
The request has been fulfilled, resulting in the creation of a new resource
The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.
203 Non-Authoritative Information (since HTTP/1.1)
The server is a transforming proxy (e.g. a
) that received a 200 OK from its origin, but is returning a modified version of the origin's response Web accelerator
204 No Content
The server successfully processed the request and is not returning any content
205 Reset Content
The server successfully processed the request, but is not returning any content. Unlike a 204 response, this response requires that the requester reset the document view.
9.3 3xx Rirection
301 Moved Permanently
This and all future requests should be directed to the given
This is an example of industry practice contradicting the standard. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"),but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours. However, some Web applications and frameworks use the 302 status code as if it were the 303.
303 See Other (since HTTP/1.1)
The response to the request can be found under another
URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.
304 Not Modified (
Indicates that the resource has not been modified since the version specified by the
request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.
305 Use Proxy (since HTTP/1.1)
The requested resource is available only through a proxy, the address for which is provided in the response. Many HTTP clients do not correctly handle responses with this status code, primarily for security reasons
306 Switch Proxy
No longer used. Originally meant "Subsequent requests should use the specified proxy
307 Temporary Redirect (since HTTP/1.1)
In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request
308 Permanent Redirect (
The request and all future requests should be repeated using another URI. 307 and 308 parallel the behaviors of 302 and 301, but
do not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly
9.4 4xx Client errors
400 Bad Request
The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing).
401 Unauthorized (
403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means "unauthenticated", i.e. the user does not have the necessary credentials. ]
Note: Some sites issue HTTP 401 when an
IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.
402 Payment Required
Reserved for future use. The original intention was that this code might be used as part of some form of
digital cash or micropayment scheme, as proposed for example by GNU Taler, but that has not yet happened, and this code is not usually used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.
The request was valid, but the server is refusing action. The user might not have the necessary permissions for a resource, or may need an account of some sort.
404 Not Found
The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
405 Method Not Allowed
A request method is not supported for the requested resource; for example, a GET request on a form that requires data to be presented via
POST, or a PUT request on a read-only resource.
406 Not Acceptable
The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request. See
407 Proxy Authentication Required (
The client must first authenticate itself with the
408 Request Timeout
The server timed out waiting for the request. According to HTTP specifications: "The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
Indicates that the request could not be processed because of conflict in the request, such as an
edit conflict between multiple simultaneous updates.
Indicates that the resource requested is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a "404 Not Found" may be used instead.
A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.
501 Not Implemented
The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).
502 Bad Gateway
The server was acting as a
gateway or proxy and received an invalid response from the upstream server.
503 Service Unavailable
The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state.
504 Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
505 HTTP Version Not Supported
The server does not support the HTTP protocol version used in the request.
506 Variant Also Negotiates (
content negotiation for the request results in a circular reference.
507 Insufficient Storage (WebDAV;
The server is unable to store the representation needed to complete the request.
508 Loop Detected (WebDAV;
The server detected an infinite loop while processing the request (sent in lieu of
208 Already Reported).
510 Not Extended (
Further extensions to the request are required for the server to fulfil it.
511 Network Authentication Required (
The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., "
captive portals" used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).
Lecturer: Lê Thị Bích Hòa
Nguyễn Duy Huy
Tô Xuân Hưởng
Nguyễn Duy Khoa
Trần Huỳnh Anh Khoa
Đồng Văn Sơn
Trương Hoàng Vĩnh
Trần Phúc Trình
Lê Trương Tuấn Nhân
Lương Tấn Trọng
Đỗ Hoàng Long
Võ Nguyễn Thành Lộc
Hà Võ Anh Nguyên