The answer you've already gotten is useful but confusing terms a bit here. All of the built-in replication solutions use the same basic mechanism: copying write-ahead log data over to a standby server.
You can move that WAL data for replication either a 16MB file at a time, using the archive_command facility, or using Streaming Replication (SR). If using SR, you really should setup archiving too, and the server will switch between them as appropriate.
You can have a warm standby server, which cannot answer queries. Or you can have a hot standby server, which can answer read-only ones. This is unrelated to how the data is getting onto the standby.
Each of these two choices combines with each of the others, and you can have all four combinations. You can have a Hot Standby answering queries while being fed with file at a time WAL segments. You can have a Streaming Replication server that does not have Hot Standby enabled, so it will not answer queries. It's just that the most common case, nowadays, is both Streaming Replication plus Hot Standby. That's the full feature set. Again, don't ignore the old archive_command mechanism just because it's possible to avoid now. It can still save you from streaming failures that are otherwise hard to recover from.