HTTP Workshop — Independent Practice: Discover and Consume a REST API

Your assignment: You have joined a development team and received a simple request: investigate a publicly documented REST API that could be useful to an application, and prove that an ABAP Cloud program can consume it. You must choose the API yourself, read its documentation, implement calls in Eclipse ADT, and explain your results.

This practice is part of the HTTP Workshop. You will not use a Service Consumption Model, OData proxy, or SAP S/4HANA connection for your chosen API. You will apply GET, POST, PUT, DELETE, JSON and authentication-header knowledge to an API you discover yourself.

Practice format: Three hours of independent work, organized by practical milestones rather than fixed time allocations.

1. Business request

Our team wants to understand whether a public REST API could supply useful information to an ABAP application. Find a suitable API, demonstrate real requests when permitted, investigate its authentication requirements, and report any restrictions. We need a clear technical handover, not just screenshots of JSON.

You are free to choose a topic: weather, geography, books, games, public transport, astronomy or another legitimate public dataset.

2. Find an API yourself

Do not simply reuse JSONPlaceholder or httpbin as your discovered API. Those are already used in the guided workshop and may still be used for the separate write/authentication tests below.

1. Search for public REST APIs using a search engine or a directory such as https://github.com/public-apis/public-apis.
2. Find at least two different candidates and open the official documentation for each.
3. Compare the candidates using this table, then choose one:

Item to investigate	Candidate A	Candidate B
API/provider name
Official documentation URL
Example HTTPS endpoint URL
What business information it returns
GET supported?
POST/PUT/DELETE supported?
Authentication requirement
Registration/key required?
Rate limits or terms to respect
Suitable for BTP Trial testing?

Choose an API with publicly accessible, non-sensitive sample data, clear documentation and a supported read-only endpoint. If an API needs a paid account or real customer credentials, choose another one.

If you need inspiration, look at https://open-meteo.com/en/docs or https://pokeapi.co/docs/v2. These are examples only; verify the documentation yourself and choose your own useful endpoint. You are encouraged to find another provider.

3. Explain how the selected API works

Before coding, write a short description of:

• the API's base URL;
• one concrete endpoint URL, including required parameters;
• the HTTP method;
• the authentication method (none, Bearer, Basic, API key or another mechanism);
• the expected HTTP success status and JSON response shape (object or array);
• at least three useful response properties;
• usage restrictions, if any.

Do not guess the endpoint by changing URLs at random. Use the documentation for the chosen provider.

4. Build your own ABAP HTTP client

Create a class such as ZCL_REST_EXPLORE_001 (replace 001 consistently) implementing IF_OO_ADT_CLASSRUN.

Use the HTTP APIs from the guided workshop:

"Adapt the official endpoint and headers to YOUR chosen API.
DATA(destination) = cl_http_destination_provider=>create_by_url(
  i_url = 'https://<official-api-host>/<documented-endpoint>' ).

DATA(client) = cl_web_http_client_manager=>create_by_http_destination(
  i_destination = destination ).

DATA(request) = client->get_http_request( ).
request->set_header_field(
  i_name  = 'Accept'
  i_value = 'application/json' ).

DATA(response) = client->execute(
  i_method = if_web_http_client=>get ).

DATA(status) = response->get_status( ).
out->write( |HTTP status: { status-code }| ).

"Check status and body before parsing into your own ABAP type.
client->close( ).

The snippet belongs inside IF_OO_ADT_CLASSRUN~MAIN and appropriate TRY...CATCH handling. It is intentionally not a complete class: the endpoint, structure and output depend on the API you discovered.

Your implementation must:

1. Send at least two distinct documented GET requests (for example, two different resource IDs, locations, or query-parameter values).
2. Display the HTTP status of each response.
3. Show at least three meaningful fields from a successful JSON response. Use XCO_CP_JSON to convert a suitable response into ABAP structures or tables when practical; complex/nested APIs may require a small adapted type.
4. Report a missing resource, invalid parameter or other documented error case without crashing. Only test errors that the provider's documentation permits.
5. Catch connection/destination exceptions and explain how they differ from HTTP 4xx/5xx responses.
6. Close the HTTP client when finished.

Evidence: ABAP source code and console output, or the fallback evidence in Section 9. Keep the console readable; you do not need to print thousands of lines of raw JSON.

5. Investigate authentication and demonstrate a header

Read the selected API's documentation and record its actual authentication rules. You are not required to register for an API key or disclose a secret.

As a separate controlled test, use the guided ZCL_REST_AUTH_001 pattern with https://httpbin.org/bearer:

1. Send Authorization: Bearer classroom-demo-token and record the status (normally 200).
2. Remove that header and try again (normally 401).
3. Explain which line of ABAP adds the header, and why 401 is different from a connection exception.
4. Explain how you would supply a Bearer token, Basic credentials or an API key in an application with secure destination configuration, without placing real secrets in your repository.

If httpbin is unavailable from ABAP Trial, label this as a documentation/offline demonstration, not as a successful HTTP call.

6. Experiment with POST, PUT and DELETE — safely

Investigate whether the API you discovered has documented test/sandbox write endpoints. You may use them only if the provider explicitly permits testing and you have authorization; never change real records in an unfamiliar system.

If your chosen API is read-only or has no documented sandbox, that is perfectly acceptable. Use JSONPlaceholder's nonpersistent training endpoints instead:

• POST https://jsonplaceholder.typicode.com/posts — submit an original JSON example of your own.
• PUT https://jsonplaceholder.typicode.com/posts/3 — send a complete replacement sample.
• DELETE https://jsonplaceholder.typicode.com/posts/3 — request a simulated delete.
• GET https://jsonplaceholder.typicode.com/posts/3 — verify that the sample record still exists.

For each permitted method, record URL, HTTP method, request body where applicable, status code and returned body if any. Do not claim that POST/PUT/DELETE permanently changed JSONPlaceholder data.

Your experiment must explain the difference between a successful HTTP response and persistence. It must also identify which tests ran against your discovered API and which used the sandbox.

7. Evaluate the API for a real ABAP application

Write a short technical recommendation answering:

• What could an ABAP application use this API for?
• Which data fields would be useful and how would you store or display them?
• What do its authentication requirements mean for implementation?
• What if the remote API returns 404, 401, 429 or a 5xx status?
• How would you avoid putting secrets in ABAP source code?
• Does the API appear suitable for occasional classroom use? Why?

For extra credit, compare two chosen APIs that solve a similar problem and explain which has clearer documentation.

8. What to submit

Submit:

1. API investigation: Two candidates, official documentation links and your selection rationale.
2. ABAP class(es): Your own runnable GET consumer and any allowed write/authentication demonstrations.
3. Execution evidence: Relevant console output including actual statuses and extracted JSON fields; distinguish remote from local/simulated results.
4. Experiment log: Two GET cases, one error scenario, Bearer with/without header (or blocked-test explanation), and the POST/PUT/DELETE sandbox checks where feasible.
5. Developer handover: A short paragraph explaining the chosen API, observed behavior, risks, and how this prepares you for Lesson 21.

Completion checklist

• I compared at least two candidate public REST APIs using official documentation.
• I chose one API other than JSONPlaceholder or httpbin.
• I identified its URL, response shape, supported methods and authentication.
• My ABAP program can make two documented GET requests, or I recorded the exact connectivity restriction.
• I interpreted status codes and meaningful response fields.
• I handled one permitted error case and distinguished it from an ABAP exception.
• I demonstrated or documented Bearer headers, with no real secrets in the output.
• I tested or documented POST, PUT and DELETE only in an authorized sandbox.
• I reported which requests were executed remotely and which were simulated/offline.
• I included a brief developer handover.

9. If your BTP Trial blocks the chosen public API

Browser success does not prove that the ABAP server can access a public website. If the chosen API fails from ABAP:

1. Record the URL host, exact ABAP exception and whether the URL works in your browser; redact secrets and private information.
2. Test another documented read-only endpoint from your alternative candidate, if available.
3. Use an official sample JSON response or a browser-observed response as an ABAP string, then practice parsing it with XCO_CP_JSON.
4. Write and activate the HTTP class with the correct method, path, headers and response checks. Explain that execution is unverified.
5. Use the publicly documented JSONPlaceholder sandbox behavior to explain GET/POST/PUT/DELETE without claiming that remote operations succeeded in ABAP.
6. If the Bearer test is also blocked, show the exact header your class would send and explain the expected 200/401 distinction.

A valid fallback submission clearly says which steps did not run remotely. Do not use SAP's shared S/4HANA Product API to experiment with writes, and never use another person's credentials or a real API key in source code.

10. Useful starting URLs

• Public API directory: https://github.com/public-apis/public-apis
• Open-Meteo API documentation: https://open-meteo.com/en/docs
• PokéAPI API documentation: https://pokeapi.co/docs/v2
• JSONPlaceholder simulated write guide: https://jsonplaceholder.typicode.com/guide/
• httpbin Bearer test: https://httpbin.org/bearer
• SAP ABAP console tutorial: https://developers.sap.com/tutorials/abap-environment-console-application/