API doesn't override namespace when using CLI

[sayden]

API doesn't override namespace when using CLI

[asim]

I'm not sure what you're implying with "current result". Namespace is not logged. Where it says "Registering node go.micro.api" that is the actual name of the api itself. The API Namespace flag basically affects how the API routes requests. It uses the namespace + path as the service name to route a request to. The default namespace is "go.micro.api" which can be seen here https://github.com/micro/micro/blob/master/api/api.go#L23 but it might be confusing that its also the name of the api itself.

Have you actually tried making requests once the namespace is changed?

[sayden]

I understand. Definitely it's a bit misleading.

The actual problem that I throght was involved with the namespace is that the RPC calls were working but not the HTTP ones.

In your example here https://github.com/micro/micro/tree/master/examples/greeter the "Test API via Curl" it always gives me:

curl http://localhost:8080/greeter/say/hello\?name\=John 
{"id":"go.micro.client","code":500,"detail":"none available","status":"Internal Server Error"}

I just copy pasted the commands in the example. It works when using the RPC endpoint.

I managed to run some code using the HTTP API but params always arrive emtpy

Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil)

I have tried POST and GET.

Any ideas?

[asim]

I have a feeling you're running the example incorrectly.

You must run:

1. Service Discovery. Default being consul
2. The greeter server in examples/greeter/server
3. The greeter api in examples/greeter/api
4. The micro api

When you curl http://localhost:8080/greeter/say/hello it will send a request to the micro api which makes a request to the greeter api and that queries the greeter server.

I have just started all of these in a terminal and get the response:

$ curl http://localhost:8080/greeter/say/hello?name=John
{"message":"Hello John"}

If using the micro api as a proxy by specifying --api_handler=proxy then you must use the go-restful api example in examples/greeter/api/go-restful which is then queried as follows:

$ curl http://localhost:8080/greeter/john
{
  "msg": "Hello john"
 }

It's difficult to know what you're running and in what configuration from that last comment. Also If you changed the API namespace then the names for example application must also be changed from go.micro.api.greeter to whatever your namespace is.

[sayden]

Ok, I managed. I deleted all contents and did go get -u again. The example worked fine.

I also didn't realize that I had to explicitly implement the api service apart from the service itself to allow HTTP queries. The fact that the RPC service worked without api using micro api made me thought that it also worked for HTTP requests.

Maybe it could be a good improvement. Do you think that micro api could parse the params and build the RPC call by itself without implementing an api service too?

[asim]

There are a number of reasons for the separation of API services. The primary reason being for architectural design purposes. Please read https://blog.micro.mu/2016/04/18/micro-architecture.html for more info.

[sayden]

Thank you for your time, Asim.

[anuragbhardwaj]

I was running the greeter/server and greeter/client example. The server starts fine, however, when I start the client as specified, it throws me an error saying {"id":"go.micro.client","code":500,"detail":"none available","status":"Internal Server Error"}

Can you please advice what I might be doing wrong here?

[asim]

Please do not comment in a closed issue. Please join the slack to discuss usage. The error implies the client cannot find the server. Please the readme to clearly understand the setup.