So...
I've been reading about REST a little bit, and the idea behind it sounds nice, but the question is, can it be easily integrated into the standard flow of a webpage?
For example, a user creates some sort of item, a blog post or what have you, and now he wants to delete it, so he clicks a 'delete' link on the page. Now what? How do we issue a DELETE request to, say, http://mysite.com/posts/5? And how do we handle that request? I have no experience with cURL or anything, but from the looks of it, I would have to curl_init('http://mysite.com/posts/5') and then work some magic. But where would I even put that script? That would have to be on another page, which would break the whole idea of REST. Then I would just be GETing another page, which would in turn DELETE the page I originally intended?
Is this why people rarely use REST or is there actually a nice way to do this?
Looks like I need to clarify. People are suggesting I include words like "DELETE" and "POST" in the URL. I believe REST dictates that we have a unique URL for each resource but not for each action on that resource. I assume this also means that we only have one and only one URL for each resource. i.e. I want to be able to DELETE or VIEW the contents of a particular post from one URL (by sending either DELETE, PUT, POST, or GET), not different URLs with additional params
With a restful server, the same url (say /books/1) can respond to many different verbs. Those verbs, GET, POST, PUT, and DELETE, together with the path, indicate what you want to do to the data on the server. The response tells you the answer to your request.
REST is about accessing data in a predictable and sensible way.
If you come from a strong PHP background, where every url has to map to a particular file, you're right, it doesn't really make sense. The two most visible RESTful development environments, ASP.NET MVC and Rails, each have special servers (or server logic) which read the verbs and do that special routing for you. That's what lets the "normal flow" of the application go through as you'd expect. For PHP, there are frameworks that help with this, such as WSO2's WSF.
How REST works with Web Browsers
Take, for instance, your example. We have posts, and we want to delete one.
We start by visiting a url like /posts/4. As we would expect, this shows post 4, its attributes, and some actions you could take on it. The request to render this url would look like GET /posts/4. The response contains HTML that describes the item.
The user clicks the "Delete Item 4" link, part of the HTML. This sends a request like DELETE /posts/4 to the server. Notice, this has re-used the /posts/4 url, but the logic must be different.
Of HTML forms and web browsers, many of them will change a link with method="delete" into a method="post" link by default. You will need to use Javascript (something like this) to change the verb. Ruby on Rails uses a hidden input field (_method) to indicate which method is to be used on a form, as an alternative.
On the server side, the "delete an item" logic is executed. It knows to execute this because of the verb in the request (DELETE), which matches the action being performed. That's a key point of REST, that the HTTP verbs become meaningful.
After deleting the item, you could respond with a page like "yep, done," or "no, sorry, you can't do that," but for a browser it makes more sense to put you somewhere else. The item being deleted, responding with a redirect to GET /posts makes good sense.
If you look at the server log, it will be very clear what everybody did to the server, but that's not as important as...
How REST works with Arbitrary Data
Another key point of REST is that it works well with multiple data formats. Suppose you were writing a program that wanted to read and interact with the blog programmatically. You might want all the posts given in XML, rather than having to scrape the HTML for information.
GET /posts/4.xml is intuitive: "Server, please give me xml describing post #4." The response will be that xml. A RESTful server makes it obvious how to get the information you want.
When you made the DELETE /posts/4.xml request, you're asking, "Server, please delete item #4." A response like, "Okay, sure," is usually sufficient to express what's happened. The program can then decide what else it wants and make another request.
Well one way is to make an AJAX call using the DELETE method.
Facebook's REST server is a pseudo one, you can do it like them, asking for the post method: POST, GET, etc. the action and the other values you need for that request.
Why I say facebook is a pseudo REST server? : well, one of the Principles of REST says
Every resource is uniquely addressable using a universal syntax for use in hypermedia links
in facebook you only have /server.php and there is where you make the request, even for (POST, GET, PUT, DELETE...)
the other way is using mod_rewrite and parse the url the client is requesting
EDIT: just found this, looks interesting. Have fun!
I don't think REST is rarely used. You're using it right now, on StackOverflow. As far as your specific example goes, you can send DELETE requests though XMLHttpRequest in browsers that support it. When JS is off, or for non-compliant browsers, you can do something like:
POST http://foo.com/delete?post=5
Not ideal, but still more restful than many sites.
EDIT: Changed to POST
Depending on what framework you use, there are models that determine how actions are handled for each resource.
Basically using another parameter, you want to send the resource what action to perform. That parameter may be sent through AJAX/JS for example.
If you want to do it without javascript/ajax (in case it's disabled), then a form POST method would work as well, sending the resource the extra ACTION parameter.
Of course, in both cases, you have to consider security, and make sure that they're not sending the resource an action they shouldn't be. Make sure to do your checking on the backend, and send an appropriate response or error message.
Client side scripting, whether through JS/Ajax or form POST or other methods require the extra security precaution.
Edited after clarification from poster.
Don't overthink it. You're not going to be able to do this with straight HTML forms and a browser. They do not support DELETE method. Ajax can do it.
I want to be able to DELETE to VIEW
the contents of a particular post from
one URL (by sending either DELETE,
PUT, POST, or GET), not different URLs
with additional params
Delete to view? I'm not sure I understand it, but your delete should be done through the headers, not through the URL. The delete method should not return a view. REST is a service, not all requests are meant for visual consumption.
If you really have no choice about using the DELETE verb then I would suggest something like the following:
POST http://mysite.com/Trashcan?resourceUrl=/Customer/75
What url you use really does not matter to REST, however, it is easier to understand the REST way of interacting if your urls avoid verbs completely.
I have seen so many questions from both Rails and ASP.NET MVC users who need to go beyond the standard "actions" and it is so tempting to just add a new action on the controller. The problem with doing this is that you just threw away the uniform interface constraint of REST.
The trashcan metaphor is not the only way of doing deletes restfully but I would argue that it is just as clear to read as putting a "delete" in the url.
Here are some more "noun-based" ways of replacing verbs.
POST http://mysite.com/Printer/75/PrintQueue?url=http://mysite.com/Document/xyz
POST http://mysite.com/CurrentLogins?user=bob
POST http://mysite.com/QueryProcessor?query=FindMyInformation
POST http://mysite.com/SearchEngine?searchTerms=cat,blue,furry
POST http://mysite.com/OrderProcessor?cart=http://mysite.com/user/2323/cart
Sometimes you have to think out of the box a little to come up with a noun based url, and may seem pedantic to try and do this, but for me the benefit comes from the ability to manage my variables. I am going to have a variable number of resources in my interface, no matter what I do, if I can fix the number of verbs that can operate on those resources then I reduce one of my variables.
Another way of doing it, assuming a webbased/webapplication-based request, is have 2 submitbuttons. Since PUT and DELETE use the same uri/url. You could add a specific delete form and attach a specific name to this delete-button, so when this is sent via a post, you can use this button-name to turn the action into a DELETE
Related
I'm creating a small application for double opt-in purposes, the user has to click on a link in a email, but this sends a GET HTTP request to my REST API. But logically requesting a REST API with GET results in getting data instead of setting data.
I have tried to use a
<form method="post" action="x.x.x.x/api/optin/double/"></form>
element to set the method to POST and creating an input element:
<input name="method" value="put" style="display:none">
to"set the method by a parameter.
But this does not seem to be the right solution.
I could create a file("accepteddooubleoptin.php") for that purpose but I'm not sure if that is the right solution. Or am I totally miss understanding the REST purpose?
There's no practical way to have a link in an email result in a POST request. The best you could do is send them to a page which displays a button which they must click which generates the POST request, but it's debatable whether you would want this flow for the user as opposed to a single click in their email.
The request is basically idempotent, i.e. even if the user clicks multiple times, it still results in them simply being in the opted-in state, so no state is repeatedly modified (as opposed to a new post being generated every time you POST to /blog/posts, for example).
In conclusion, it's alright, just use the GET request.
GET is a perfectly acceptable way to accomplish what you're trying to accomplish.
It's not a bad instinct to want to use your GET/POST/PATCH/DELETE verbs in their most literal sense, but this is one case where the technology (i.e., modern email clients) all but makes the decision for you. And there's nothing wrong with that.
See this short post from Campaign Monitor explaining what it looks like when you try to generate a POST request in an email. In short, the user's email client gets weirded out at best.
In fact, if you take a look at account verification or password reset emails from any popular web service (even StackOverflow, for example), you'll find you're in good company in that they use links with query strings to pass tokens or account identifiers in order to drop the user into the right workflow on their sites.
If you're still uncomfortable with the idea of "setting" a value via GET, you might think of it more like your user is clicking their link to "get" the appropriate form through which they ultimately "set" their preference.
Is it correct using “GET” as method for changing data in REST API
The important thing to understand about the standard meaning of GET is that it has safe semantics. Here is how Fielding described the matter in 2002.
HTTP does not attempt to require the results of a GET to be safe. What it does is require that the semantics of the operation be safe, and therefore it is a fault of the implementation, not the interface or the user of that interface, if anything happens as a result that causes loss of property (money, BTW, is considered property for the sake of this definition).
Because the semantics of the request are supposed to be safe, the email client is allowed to send a request before the recipient clicks on the link! For instance, the client might pro-actively load the response into a cache so that the latency for the human being is reduced if the link does get clicked.
For a use case like "Opt In", you really need to be thinking about what liabilities you incur if that link is fetched without the explicit consent of the human being.
The right way to do it would be to use an unsafe request (like POST).
However, implementing Opt In the "right" way may have a significant impact on your acceptance rate; the business might prefer to accept the liability rather than losing the opportunities.
Is it wrong to use POST for everything in REST? I know POST is for updating and creating but what if I use it for SELECTS and DELETS as well? What I basically need is a web service that can do CRUD operations to a database. Im using PHP. Also, what if I use query strings to do the POST request instead of using JSON or XML?
If you're using POST for all operations, you can't really call it REST anymore.
So it's not wrong, but it's not REST either :)
Yes, it's wrong. If you are using POST for anything other than updating you aren't actually following the REST convention.
You can eat soup with fork but why? Anyway you can use any method, just don't call it REST protocol.
Is it wrong to use POST for everything in REST?
You can't use POST for everything in REST (e.g. only for requests, not responses), so the question about wrong or right is not a valid question.
I know POST is for updating and creating but what if I use it for SELECTS and DELETS as well?
It normally just works.
What I basically need is a web service that can do CRUD operations to a database.
That's fine.
Im using PHP.
That's fine, too. PHP hast support for the HEAD, GET and POST method. For the PUT and DELETE methods you need to do a little bit more coding.
Also, what if I use query strings to do the POST request instead of using JSON or XML?
You use query strings instead of JSON/XML request bodies. REST does not specify the protocol, so you can do whatever pleases you. Using "query strings" might be a good idea with PHP as PHP supports those out of the box. But it depends what you use for a handler or what you want to support.
As your questions are very broad, you might want to read some basic description of REST first before so you can more specifically ask: A Brief Introduction to REST.
It's wrong to use POST for calls that are meant to be repeatable.
POST calls are never cached but your select calls should be cache-able (and repeatable) so you shouldn't be using POST for them.
But there's no technical reason why you can't force everything through POST, (particularly as DELETE isn't supported across all browsers), but it does mean that caching won't work for any of your calls, and also that your users may not be able to refresh a web page without being asked to confirm page reload if POST calls have been made to create it.
At this REST tutorial here the 4th article in the series says:
For creation, updating, and deleting data, use POST requests. (POST can also be used for read-only queries, as noted above, when complex parameters are required.)
Of course GET is usually used for read-only queries, so putting it all together, if complexity is the default assumption, which is kind of a handy assumption when no threshold between complexity and simplicity is stated, then this guy who is enough an authority to write a whole series on REST is saying that it's okay to POST everything. May be caches make some assumptions about responses to various HTTP verbs that might be beneficial but if your application does not benefit from caching (indeed, might be harmed by it, so disable it or do something so your application does not suffer from it) then I don't know if there's any problem at all.
I want to hide parameters from URL. I'm using uuids instead of ids and when I pass it in URL it looks a bit long and ugly. First thought was to use little forms with hidden inputs istead of anchors, but it will be uncomfortable to replace every one anchor with form, also it will not work when an anchor is placed in another form already.
So second thought was rewriting $_GET to $_POST/$_SESSION and then redirect again to this script. All variables will be available and the URL will be clean and short.
But what with performance of this solution? Is it a good idea to do it this way?
Any help or other ideas will be appreciated. Thanks in advance.
PS.
Don't change GET to POST or vice versa for prettiness. Both HTTP methods are handled very differently in many contexts, and you don't want to cause these kind of side effects.
POST requests cannot be self-contained in a URL, i.e. try to send someone the link to a site that requires a POST request. POST requests screw with browser history, i.e. try clicking the back button to go back to a page submitted via POST. POST requests aren't indexed by search engines.
POST requests are supposed to be used to modify data on the server. Don't use them for all regular requests.
If you need prettier URLs, find some other way to reference your records. Or just stop caring about it, it's really not that important.
you will of course loose ALL search engine benefits across the entire width of your site if you universaly adopt this strategy. you should only really use $_POST when you are submitting data that needs to be saved to a storage medium (or where you are sending secure data https etc), otherwise the recommendation is $_GET for 'requested' data. So, you'll need to identify the use case here and follow that pattern.
I understand what you are saying about 'ugly' URLs, but would advise you to be cautious on looking for remedial action on this. One way of course would be to do a urlrewrite on the incoming parameters but this would require database lookups etc (to get the mapped nice url string), so could be costly.
I'll get back with any other thoughts as they occur.
So, I was looking through some articles on creating REST API's.
And some of them suggest using all types of HTTP requests: like PUT DELETE POST GET.
We would create for example index.php and write API this way:
$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(#$_SERVER['PATH_INFO'], 1));
switch ($method) {
case 'PUT':
....some put action....
break;
case 'POST':
....some post action....
break;
case 'GET':
....some get action....
break;
case 'DELETE':
....some delete action....
break;
}
OK, granted - I don't know much about web services (yet).
But, wouldn't it be easier to just accept JSON object through regular POST or GET (that would contain method name and all parameters) and then respond in JSON as well. We can easily serialize/deserialize via PHP's json_encode() and json_decode() and do whatever we want with that data without having to deal with different HTTP request methods.
Am I missing something?
UPDATE 1:
Ok - after digging through various API's and learning a lot about XML-RPC, JSON-RPC, SOAP, REST I came to a conclusion that this type of API is sound. Actually stack exchange is pretty much using this approach on their sites and I do think that these people know what they are doing Stack Exchange API.
The idea of REpresentational State Transfer is not about accessing data in the simplest way possible.
You suggested using post requests to access JSON, which is a perfectly valid way to access/manipulate data.
REST is a methodology for meaningful access of data. When you see a request in REST, it should immediately be apparant what is happening with the data.
For example:
GET: /cars/make/chevrolet
is likely going to return a list of chevy cars. A good REST api might even incorporate some output options in the querystring like ?output=json or ?output=html which would allow the accessor to decide what format the information should be encoded in.
After a bit of thinking about how to reasonably incorporate data typing into a REST API, I've concluded that the best way to specify the type of data explicitly would be via the already existing file extension such as .js, .json, .html, or .xml. A missing file extension would default to whatever format is default (such as JSON); a file extension that's not supported could return a 501 Not Implemented status code.
Another example:
POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }
is likely going to create a new chevy malibu in the db with the associated colors. I say likely as the REST api does not need to be directly related to the database structure. It is just a masking interface so that the true data is protected (think of it like accessors and mutators for a database structure).
Now we need to move onto the issue of idempotence. Usually REST implements CRUD over HTTP. HTTP uses GET, PUT, POST and DELETE for the requests.
A very simplistic implementation of REST could use the following CRUD mapping:
Create -> Post
Read -> Get
Update -> Put
Delete -> Delete
There is an issue with this implementation: Post is defined as a non-idempotent method. This means that subsequent calls of the same Post method will result in different server states. Get, Put, and Delete, are idempotent; which means that calling them multiple times should result in an identical server state.
This means that a request such as:
Delete: /cars/oldest
could actually be implemented as:
Post: /cars/oldest?action=delete
Whereas
Delete: /cars/id/123456
will result in the same server state if you call it once, or if you call it 1000 times.
A better way of handling the removal of the oldest item would be to request:
Get: /cars/oldest
and use the ID from the resulting data to make a delete request:
Delete: /cars/id/[oldest id]
An issue with this method would be if another /cars item was added between when /oldest was requested and when the delete was issued.
This is a security and maintainability question.
safe methods
Whenever possible, you should use 'safe' (unidirectional) methods such as GET and HEAD in order to limit potential vulnerability.
idempotent methods
Whenever possible, you should use 'idempotent' methods such as GET, HEAD, PUT and DELETE, which can't have side effects and are therefore less error prone/easier to control.
Source
In short, REST emphasizes nouns over verbs. As your API becomes more complex, you add more things, rather than more commands.
You asked:
wouldn't it be easier to just accept JSON object through normal $_POST and then respond in JSON as well
From the Wikipedia on REST:
RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of it
From what (little) I've seen, I believe this is usually accomplished by maximizing the use of existing HTTP verbs, and designing a URL scheme for your service that is as powerful and self-evident as possible.
Custom data protocols (even if they are built on top of standard ones, such as SOAP or JSON) are discouraged, and should be minimized to best conform to the REST ideology.
SOAP RPC over HTTP, on the other hand, encourages each application designer to define a new and arbitrary vocabulary of nouns and verbs (for example getUsers(), savePurchaseOrder(...)), usually overlaid onto the HTTP 'POST' verb. This disregards many of HTTP's existing capabilities such as authentication, caching and content type negotiation, and may leave the application designer re-inventing many of these features within the new vocabulary.
The actual objects you are working with can be in any format. The idea is to reuse as much of HTTP as possible to expose your operations the user wants to perform on those resource (queries, state management/mutation, deletion).
You asked:
Am I missing something?
There is a lot more to know about REST and the URI syntax/HTTP verbs themselves. For example, some of the verbs are idempotent, others aren't. I didn't see anything about this in your question, so I didn't bother trying to dive into it. The other answers and Wikipedia both have a lot of good information.
Also, there is a lot to learn about the various network technologies built on top of HTTP that you can take advantage of if you're using a truly restful API. I'd start with authentication.
In regards to using extension to define data type.
I noticed that MailChimp API is doing it, but I don't think this is a good idea.
GET /zzz/cars.json/1
GET /zzz/cars.xml/1
My sound like a good idea, but I think "older" approach is better - using HTTP headers
GET /xxx/cars/1
Accept: application/json
Also HTTP headers are much better for cross data type communication (if ever someone would need it)
POST /zzz/cars
Content-Type: application/xml <--- indicates we sent XML to server
Accept: application/json <--- indicates we want get data back in JSON format
Am I missing something?
Yes. ;-)
This phenomenon exists because of the uniform interface constraint. REST likes using already existing standards instead of reinventing the wheel. The HTTP standard has already proven to be highly scalable (the web is working for a while). Why should we fix something which is not broken?!
note: The uniform interface constraint is important if you want to decouple the clients from the service. It is similar to defining interfaces for classes in order to decouple them from each other. Ofc. in here the uniform interface consists of standards like HTTP, MIME types, URI, RDF, linked data vocabs, hydra vocab, etc...
Good Semantics is important in programming.
Utilizing more methods besides GET/POST will be helpful because it will increase the readability of your code and make it easier to maintain.
Why?
Because you know GET will retrieve data from your api. You know POST will add new data to your system. You know PUT will make updates. DELETE will delete rows etc, etc,
I normally structure my RESTFUL Web Services so that I have a function callback named the same thing as the method.
I use PHP, so I use function_exists (I think its called). If the function doesn't exist, I throw a 405 (METHOD NOT ALLOWED).
Bill Venners: In your blog post entitled "Why REST Failed," you said that we need all four HTTP verbs—GET, POST, PUT, and DELETE— and lamented that browser vendors only GET and POST." Why do we need all four verbs? Why aren't GET and POST enough?
Elliotte Rusty Harold: There are four basic methods in HTTP: GET, POST, PUT, and DELETE. GET is used most of the time. It is used for anything that's safe, that doesn't cause any side effects. GET is able to be bookmarked, cached, linked to, passed through a proxy server. It is a very powerful operation, a very useful operation.
POST by contrast is perhaps the most powerful operation. It can do anything. There are no limits as to what can happen, and as a result, you have to be very careful with it. You don't bookmark it. You don't cache it. You don't pre-fetch it. You don't do anything with a POST without asking the user. Do you want to do this? If the user presses the button, you can POST some content. But you're not going to look at all the buttons on a page, and start randomly pressing them. By contrast browsers might look at all the links on the page and pre-fetch them, or pre-fetch the ones they think are most likely to be followed next. And in fact some browsers and Firefox extensions and various other tools have tried to do that at one point or another.
PUT and DELETE are in the middle between GET and POST. The difference between PUT or DELETE and POST is that PUT and DELETE are *idempotent, whereas POST is not. PUT and DELETE can be repeated if necessary. Let's say you're trying to upload a new page to a site. Say you want to create a new page at http://www.example.com/foo.html, so you type your content and you PUT it at that URL. The server creates that page at that URL that you supply. Now, let's suppose for some reason your network connection goes down. You aren't sure, did the request get through or not? Maybe the network is slow. Maybe there was a proxy server problem. So it's perfectly OK to try it again, or again—as many times as you like. Because PUTTING the same document to the same URL ten times won't be any different than putting it once. The same is true for DELETE. You can DELETE something ten times, and that's the same as deleting it once.
By contrast, POST, may cause something different to happen each time. Imagine you are checking out of an online store by pressing the buy button. If you send that POST request again, you could end up buying everything in your cart a second time. If you send it again, you've bought it a third time. That's why browsers have to be very careful about repeating POST operations without explicit user consent, because POST may cause two things to happen if you do it twice, three things if you do it three times. With PUT and DELETE, there's a big difference between zero requests and one, but there's no difference between one request and ten.
Please visit the url for more details. http://www.artima.com/lejava/articles/why_put_and_delete.html
Update:
Idempotent methods
An idempotent HTTP method is a HTTP method that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. Again, this only applies to the result, not the resource itself. This still can be manipulated (like an update-timestamp, provided this information is not shared in the (current) resource representation.
Consider the following examples:
a = 4;
a++;
The first example is idempotent: no matter how many times we execute this statement, a will always be 4. The second example is not idempotent. Executing this 10 times will result in a different outcome as when running 5 times. Since both examples are changing the value of a, both are non-safe methods.
Basically REST is (wiki):
Client–server architecture
Statelessness
Cacheability
Layered system
Code on demand (optional)
Uniform interface
REST is not protocol, it is principles.
Different uris and methods - somebody so called best practices.
I have an HTML menu with links like <a href="input&db=<some database>" There are multiple menu items and multiple databases, so I am using GET as my form method and using it in my menu item links.
However, that shows up in the browser's address bar (as /inout&db=mydatabase) & might lead the user to start guessing as to database names.
How can I have a list of links to the same page, in which only the database varies, using $_POST ?
EDIT: oops, my bad Shoulda said server-side only, so no JS
POST values will be just as obvious to anyone who would be savvy enough to do anything with this information. Unless you're building something like phpMyAdmin, you should never pass such internal information to the client side to begin with. And if you are, where's the harm? You do have proper authentication in place, don't you?
I think the only way to send request via post using links is to use JavaScript. But sending it via post is not secure at all; anyone can install FireBug to see the request.
Instead, I'll suggest a change to your design. Databases are usually at the bottom tier in an application hierarchy, and coupling page details with database sounds unnecessary. Maybe you should try to encapsulate pages so that they don't need to know which database they are reading from?
Granted, I have no idea of the scope of your application (you may be doing something like phpmyadmin). Then it may be unavoidable, and I will just suggest the usual combination of verification and sanctification all users' input and their rights.
Or you can just encrypt your database names. Still I would prefer a change to design.
Use the onclick event of the anchors to submit a hidden POST form, or to perform AJAX POST actions.
No. There are a few narrow and dangerous solutions you can apply:
Use an iframe : everything will work as before, but the actual address will not appear in the browser address bar.
Use AJAX to fetch data.
Replace the link with a form-submitting button or javascript: link.
These all solve the "database name appears in address bar" issue, however:
Anyone with even basic technical skills and appropriate tools (chrome, firebug) can determine the database name anyway by looking at the requests being sent out.
Not using GET can mess up the browser's back and refresh buttons, and prevent deep linking.
My suggestion would be to keep using GET as you currently are, but add a secret token to the URL (such as HMAC(db_name,secret_key)) that cannot be guessed by the user but can be easily checked for validity by the server. This way, unless you give the user a link to the database (with both database name and secret token), all the guessing in the world will not let them access it.
Neither GET or POST will hide your database name.
Even you using POST, view source will reveal the HTML.
In the first place, you should not expose your database name.
Or replace it with some fuzzy mapping
such as
input&db=A
input&db=B
Internally, do string matching and convertA to actual database name