Freecodecamp: API Basejump URL Shortener - POST instead of GET

[jondcoleman]

Since this exercise is teaching API creation, shouldn't new records be added with a POST rather than a GET request based on REST API best practices?

In addition to API best practices, some users are running into issues because Chrome (and maybe other browsers) actually issue multiple GET requests when a URL is requested (see here). This is causing confusion for these users because multiple records are being inserted into their database with each request.

[ltegman]

Yes, I think this was made a GET to make it easy to test using the address bar, but we shouldn't be breaking REST conventions just for that. This challenge should definitely be restructured to use POST.

[QuincyLarson]

@jondcoleman @ltegman thanks for pointing this out.

@Em-Ant does our new version of the URL shortener use a GET or a POST?

[Em-Ant]

@QuincyLarson It uses GET, like the old example. I agree with @ltegman in theory we should use POST. I can easily modify it to use POST, but then campers will need some external tools like curl or postman, or they'll need to provide a submission form in the front-end to interact with the API.
For our future testing system there should not be problem with both methods.

Should I change the method used to add urls ?

[QuincyLarson]

@Em-Ant we don't want campers to have to install a tool like Postman just to complete this challenge. It's also kind of inconvenient for them to have to build a front end. Could we build a simple front end for them with a submit form then tell them to just use that? One of the key aspects of our challenges is that we want them to be modular, to where you don't need to know HTML/CSS to be able to complete these challenges and projects.

[jondcoleman]

I don't think that a interface to the API needs to be specified (e.g. front end, postman, curl, etc). The user can test/consume their API in any way they choose to. The File Upload Microservice already requires a POST but doesn't specify how to actually send the POST requires.

[ltegman]

@QuincyLarson It is cumbersome, but I think it's an important part of working on an API. Learning a tool like Postman or curl or HTTPie is vital for testing an API that doesn't have a frontend, which is very often the case when working on a team of multiple people.

[Em-Ant]

@QuincyLarson where should we place the front end form (if we decide to use it) ? In the microservice boilerplate ? In a separate project (e.g. some time ago I built this to test my apis, before getting used to curl ) ? In the FCC client ?

[QuincyLarson]

@Em-Ant I think we should have it in place already in the microservice boilerplate so that it isn't necessary.

I've actually been thinking that we could have standard views for our dynamic web app projects already in place so that campers can focus purely on the back end aspects of building full stack apps instead of having to also focus on HTML and CSS. The dynamic web apps aren't very front end intensive, anyway. This would make it easier for us to test these dynamic web apps, too.

[Em-Ant]

@QuincyLarson if We use only one boilerplate for all the microservices, campers will need to wire the form to the related endpoint, where appropriate. The 2 projects that require a form also need different data encoding (multipart for the file uploader, urlencoded - or json - here).

The alternative is having one boilerplate for each project.

[QuincyLarson]

@Em-Ant so it's not possible to use different encoding types for different views? Would it be possible for us to update these challenges to use the same form of encoding?

[Em-Ant]

The base microservice boilerplate https://shimmer-ripper.hyperdev.space/ has only 1 demo endpoint GET /hello. I can add a demo POST endpoint with a form, but campers will need to change the API urls according to the current exercise.
An html form (without ajax) can send urlencoded string data pairs, or multipart encoded binaries (see https://gist.github.com/joyrexus/524c7e811e4abf9afe56). The last microservice requires file uploading. In theory we could use multipart encoding everywhere, but it's not the usual way. The server also needs to be configured to accept multipart data using different packages from the body-parser. This is taught in the advanced-express challenges.

[Em-Ant]

Closing. We restructured the challenge using POST