This exercise introduces the SPRING framework.
You'll start using the HTTP protocol, using Postman, and discovering how to manage dependencies with Maven.
Level 1:
Spring and Maven exercise:
This exercise is a first contact with Spring and Maven.
Access the page: https://start.spring.io/, and generate a Spring boot project with the following characteristics:
Import it into Eclipse using the option File > Import > Existing Maven Project.
In the application.properties file, set the server.port variable to the value 9000.
We will turn this application into a REST API:
Depending on the main package, create another subpackage called Controllers, and inside it, add the HelloWorldController class. It must have two methods:
String hi
String hi2
These two methods will receive a String parameter called name, and will return the phrase:
“Hello, “ + name + “. You are running a Maven project”.
The first method will respond to a GET request, and must be configured to receive the parameter as a RequestParam. The "name" parameter will have the default value "UNKNOWN". You will have to answer to:
The second method will respond to a GET request, and must be configured to receive the parameter as a PathVariable. The "name" parameter will be optional. You will have to answer to:
In addition to the Git link for the solved assignment, you will need to include at least two different links to the resources we have provided you with on campus that have helped or could have helped you solve the entire assignment or some parts.
Depending on the main package, create another subpackage called Controllers, and inside it, add the HelloWorldController class. It must have two methods:
String hi
String hi2
These two methods will receive a String parameter called name, and will return the phrase:
“Hello, “ + name + “. You are running a Maven project”.
The first method will respond to a GET request, and must be configured to receive the parameter as a RequestParam. The "name" parameter will have the default value "UNKNOWN". You will have to answer to:
The second method will respond to a GET request, and must be configured to receive the parameter as a PathVariable. The "name" parameter will be optional. You will have to answer to:
In addition to the Git link for the solved assignment, you will need to include at least two different links to the resources we have provided you with on campus that have helped or could have helped you solve the entire assignment or some parts.
Install Wireshark, filtering the traffic from postman/chrome to localhost by Loopback filter, to study and understand HTTP get/response traffic and layer arquitecture:
HTTP y conexiones
Una conexión se gestiona al nivel de la capa de trasporte, y por tanto queda fuera del alcance del protocolo HTTP. Aún con este factor, HTTP no necesita que el protocolo que lo sustenta mantenga una conexión continua entre los participantes en la comunicación, solamente necesita que sea un protocolo fiable o que no pierda mensajes (como mínimo, en todo caso, un protocolo que sea capaz de detectar que se ha pedido un mensaje y reporte un error). De los dos protocolos más comunes en Internet, TCP es fiable, mientras que UDP, no lo es. Por lo tanto HTTP, se apoya en el uso del protocolo TCP, que está orientado a conexión, aunque una conexión continua no es necesaria siempre.
Use HTTP Verbs to Make Your Requests Mean Something
Generally, the four primary HTTP verbs are used as follows:
GET
Read a specific resource (by an identifier) or a collection of resources.
PUT
Update a specific resource (by an identifier) or a collection of resources. Can also be used to create a specific resource if the resource identifier is known before-hand.
DELETE
Remove/delete a specific resource by an identifier.
POST
Create a new resource. Also a catch-all verb for operations that don't fit into the other categories.
Provide Sensible Resource Names
Producing a great API is 80% art and 20% science. Creating a URL hierarchy representing sensible resources is the art part. Having sensible resource names (which are just URL paths, such as /customers/12345/orders) improves the clarity of what a given request does.
Appropriate resource names provide context for a service request, increasing understandability of the API. Resources are viewed hierarchically via their URI names, offering consumers a friendly, easily-understood hierarchy of resources to leverage in their applications.
Here are some quick-hit rules for URL path (resource name) design:
Use identifiers in your URLs instead of in the query-string. Using URL query-string parameters is fantastic for filtering, but not for resource names.
Good: /users/12345
Poor: /api?type=user&id=23
Leverage the hierarchical nature of the URL to imply structure.
Design for your clients, not for your data.
Resource names should be nouns. Avoid verbs as resource names, to improve clarity. Use the HTTP methods to specify the verb portion of the request.
Use plurals in URL segments to keep your API URIs consistent across all HTTP methods, using the collection metaphor.
Avoid using collection verbiage in URLs. For example 'customer_list' as a resource. Use pluralization to indicate the collection metaphor (e.g. customers vs. customer_list).
Use lower-case in URL segments, separating words with underscores ('_') or hyphens ('-'). Some servers ignore case so it's best to be clear.
Keep URLs as short as possible, with as few segments as makes sense.
Use HTTP Response Codes to Indicate Status
Response status codes are part of the HTTP specification. There are quite a number of them to address the most common situations. In the spirit of having our RESTful services embrace the HTTP specification, our Web APIs should return relevant HTTP status codes. For example, when a resource is successfully created (e.g. from a POST request), the - - API should return HTTP status code 201. A list of valid HTTP status codes is available here which lists detailed descriptions of each.
Suggested usages for the "Top 10" HTTP Response Status Codes are as follows:
200 OK
General success status code. This is the most common code. Used to indicate success.
201 CREATED
Successful creation occurred (via either POST or PUT). Set the Location header to contain a link to the newly-created resource (on POST). Response body content may or may not be present.
204 NO CONTENT
Indicates success but nothing is in the response body, often used for DELETE and PUT operations.
400 BAD REQUEST
General error for when fulfilling the request would cause an invalid state. Domain validation errors, missing data, etc. are some examples.
401 UNAUTHORIZED
Error code response for missing or invalid authentication token.
403 FORBIDDEN
Error code for when the user is not authorized to perform the operation or the resource is unavailable for some reason (e.g. time constraints, etc.).
404 NOT FOUND
Used when the requested resource is not found, whether it doesn't exist or if there was a 401 or 403 that, for security reasons, the service wants to mask.
405 METHOD NOT ALLOWED
Used to indicate that the requested URL exists, but the requested HTTP method is not applicable. For example, POST /users/12345 where the API doesn't support creation of resources this way (with a provided ID). The Allow HTTP header must be set when returning a 405 to indicate the HTTP methods that are supported. In the previous case, the header would look like "Allow: GET, PUT, DELETE"
409 CONFLICT
Whenever a resource conflict would be caused by fulfilling the request. Duplicate entries, such as trying to create two customers with the same information, and deleting root objects when cascade-delete is not supported are a couple of examples.
500 INTERNAL SERVER ERROR
Never return this intentionally. The general catch-all error when the server-side throws an exception. Use this only for errors that the consumer cannot address from their end.
Offer Both JSON and XML
Favor JSON support unless you're in a highly-standardized and regulated industry that requires XML, schema validation and namespaces, and offer both JSON and XML unless the costs are staggering. Ideally, let consumers switch between formats using the HTTP Accept header, or by just changing an extension from .xml to .json on the URL.
Be aware that as soon as we start talking about XML support, we start talking about schemas for validation, namespaces, etc. Unless required by your industry, avoid supporting all that complexity initially, if ever. JSON is designed to be simple, terse and functional. Make your XML look like that if you can.
In other words, make the XML that is returned more JSON-like — simple and easy to read, without the schema and namespace details present, just data and links. If it ends up being more complex than this, the cost of XML will be staggering. In my experience no one has used XML responses anyway for the last several years, it's just too expensive to consume.
Note that JSON-Schema offers schema-style validation capabilities, if you need that sort of thing.
Create Fine-Grained Resources
When starting out, it's best to create APIs that mimic the underlying application domain or database architecture of your system. Eventually, you'll want aggregate services that utilize multiple underlying resources to reduce chattiness. However, it's much easier to create larger resources later from individual resources than it is to create fine-grained or individual resources from larger aggregates. Make it easy on yourself and start with small, easily defined resources, providing CRUD functionality on those. You can create those use-case-oriented, chattiness-reducing resources later.
Consider Connectedness
-One of the principles of REST is connectedness—via hypermedia links (search HATEOAS). While services are still useful without them, APIs become more self-descriptive and discoverable when links are returned in the response. At the very least, a 'self' link reference informs clients how the data was or can be retrieved. Additionally, utilize the HTTP Location header to contain a link on resource creation via POST (or PUT). For collections returned in a response that support pagination, 'first', 'last', 'next' and 'prev' links at a minimum are very helpful.
Regarding linking formats, there are many. The HTTP Web Linking Specification (RFC5988) explains a link as follows:
a link is a typed connection between two resources that are identified by Internationalised Resource Identifiers (IRIs) [RFC3987], and is comprised of:
A context IRI,
a link relation type
a target IRI, and
optionally, target attributes.
A link can be viewed as a statement of the form "{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}."
At the very least, place links in the HTTP Link header as recommended in the specification, or embrace a JSON representation of this HTTP link style (such as Atom-style links, see: RFC4287) in your JSON representations. Later, you can layer in more complex linking styles such as HAL+JSON, Siren, Collection+JSON, and/or JSON-LD, etc. as your REST APIs become more mature.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent