Allow only GET in REST API

Question

I'm developing a REST API. I need a way to get all Countries, to allow the user to select several and save an application configuration.

I'm thinking in a resource with just a GET option, since INSERT/UPDATE/DELETE are not allowed. Does it make sense?.

In general, what is the best way to provide read-only access to data?, e.g. bind a select with countries or cities or whatever data need.

Edited:

It is not related to any specific framework. The API does allow CRUD operation, in some situations I need to provide read-only access, e.g. in a form to allow the user to select a country. That form is part of a CRUD operation, but I need the countries to bind a select input so the user can select them, so the way to get all countries is to provide a url(resource) to get them.

If that helps, besides the API I'm designing the user interface of the application who will consume it. Hence I need a way to extract all countries to let the user select them and save the form. The saving of the form is a POST to a resource which have a country field(attribute).

Answer 1

inf3rnos comment, even its short is the correct answer:
You don't have to allow every HTTP method a.k.a verbs (see list of the standard ones or longer list here) on an entity. I would go even further: I think I never have seen any real life API with all HTTP methods allowed on any entity, so excluding them is not problem.

There is even a HTTP method called OPTIONS (see http method overview or longer explanation), so clients can check which methods are allowed/possible on an entity.
Sitenote: Your framework will most likely build this method on its own for you.

So only allowing GET on an entity is completely ok and standard procedure. "Famous" examples are e.g. PayPal refunds or Facebook friendlists and there lots more if you just search for random REST APIs.

---

There is just one part in your question, I am concerned about:

I'm developing a REST API. I need a way to get all Countries, to allow the user to select several and save an application configuration.

I hope that's just additional information and not related to the planned GET requests, because GET should never "do any action" (e.g. "saving", "selecting" as the HTTP specs state:

[...] the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.