goplus / yap Goto Github PK

Yet Another Go/Go+ HTTP Web Framework

License: Apache License 2.0

Go 99.94% Prolog 0.06%

yap's Introduction

yap - Yet Another Go/Go+ HTTP Web Framework

This repo contains three Go+ classfiles. They are yap (a HTTP Web Framework), yaptest (a HTTP Test Framework) and ydb (a Go+ Database Framework).

The classfile yap has the file suffix .yap. The classfile yaptest has the file suffix _ytest.gox. And the classfile ydb has the file suffix _ydb.gox.

Before using yap, yaptest or ydb, you need to add github.com/goplus/yap to go.mod:

gop get github.com/goplus/yap@latest

For more details, see YAP Framework Manual.

How to use in Go+

First let us initialize a hello project:

gop mod init hello

Then we have it reference a classfile called yap as the HTTP Web Framework:

gop get github.com/goplus/yap@latest

Create a file named get.yap with the following content:

html `<html><body>Hello, YAP!</body></html>`

Execute the following commands:

gop mod tidy
gop run .

A simplest web program is running now. At this time, if you visit http://localhost:8080, you will get:

Hello, YAP!

yap: HTTP Web Framework

This classfile has the file suffix .yap.

Router and Parameters

YAP uses filenames to define routes. get.yap's route is get "/" (GET homepage), and get_p_#id.yap's route is get "/p/:id" (In fact, the filename can also be get_p_:id.yap, but it is not recommended because : is not allowed to exist in filenames under Windows).

Let's create a file named get_p_#id.yap with the following content:

json {
	"id": ${id},
}

Execute gop run . and visit http://localhost:8080/p/123, you will get:

{"id": "123"}

YAP Template

In most cases, we don't use the html directive to generate html pages, but use the yap template engine. See get_p_#id.yap:

yap "article", {
	"id": ${id},
}

It means finding a template called article to render. See yap/article_yap.html:

<html>
<head><meta charset="utf-8"/></head>
<body>Article {{.id}}</body>
</html>

Run at specified address

By default the YAP server runs on localhost:8080, but you can change it in main.yap file:

run ":8888"

Static files

Static files server demo (main.yap):

static "/foo", FS("public")
static "/"

run ":8080"

yaptest: HTTP Test Framework

yaptest is a web server testing framework. This classfile has the file suffix _ytest.gox.

Suppose we have a web server (foo/get_p_#id.yap):

json {
	"id": ${id},
}

Then we create a yaptest file (foo/foo_ytest.gox):

mock "foo.com", new(AppV2)  // name of any YAP v2 web server is `AppV2`

id := "123"
get "http://foo.com/p/${id}"
ret 200
json {
	"id": id,
}

The directive mock creates the web server by mockhttp. Then we write test code directly.

You can change the directive mock to testServer (see foo/bar_ytest.gox), and keep everything else unchanged:

testServer "foo.com", new(AppV2)

id := "123"
get "http://foo.com/p/${id}"
ret 200
json {
	"id": id,
}

The directive testServer creates the web server by net/http/httptest and obtained a random port as the service address. Then it calls the directive host to map the random service address to foo.com. This makes all other code no need to changed.

For more details, see yaptest - Go+ HTTP Test Framework.

ydb: Database Framework

This classfile has the file suffix _ydb.gox.

TODO

yap's People

Contributors

Stargazers

Watchers

Forkers

xushiwei ironicbo visualfc baihhh wu-jj liuscraft terryw-tx carlji aofei

yap's Issues

Yap doesn't seem to support middleware

Yap doesn't seem to support middleware, so I'm having trouble wrapping cross-domain middleware and jwt middleware.

I want to add interceptor functionality to yap

Implementation plan

4 maps are saved in the interceptor to handle different situations respectively.

Why do we need 4 maps?

Because we have to deal with two fuzzy and precise matching situations of /order/:id/:name and /order/save.

process:
0. Is the path allowed?

Match the precise path
If the match fails, traverse the loop and use regular expressions to match the path.
If the match still fails, there will be no interceptor

detail:
There are two paths in fuzzy matching

/order/:id/:name
/order/get/:id

The request path is:/order/get/1
Should match: /order/get:/id
However, /order/:id/:name may be matched, so the fuzzy matches need to be sorted, and the less fuzzy ones can be ranked first.

type interceptor struct {
	
	allowIntercept map[string]func(ctx *Context)

	
	fuzzyMathAllowInterceptor map[string]func(ctx *Context)

	denyIntercept map[string]func(ctx *Context)
	
	fuzzyMathDenyInterceptor map[string]func(ctx *Context)
}

Support static file server.

Support static file server like FileServer in std http.

http.FileServer(http.Dir("./static"))

Proposal for enhanced routing mechanism to support multi-method and wildcard-method syntax

Introduction

The current routing mechanism in Yap, exemplified by file names like get_p_#id.yap, effectively maps a single HTTP method to a specific route, e.g., GET /p/:id. However, this approach presents limitations when one wishes to register multiple HTTP methods for the same route or utilize a wildcard to match any method for a given route. This proposal aims to extend the current routing syntax to accommodate these use cases.

Proposed enhancements

Support for multiple methods: To allow multiple methods to be associated with a single route, I propose a syntax where methods are concatenated using a , sign. For instance, get,head_p_#id.yap would register the /p/:id route for both GET and HEAD methods.
Wildcard method support: To enable a route to respond to any HTTP method, I propose the use of an * prefix. For example, *_p_#id.yap would match the /p/:id route for any HTTP method. This would replace the existing but less intuitive handle_p_#id.yap, aligning with the more recognized wildcard symbol *. (HANDLE is not a standard HTTP method, but non-standard methods are allowed in the HTTP spec, e.g., WebDAV uses many non-standard methods.)

Conflict resolution

In cases where multiple files might match a request (e.g., *_p_#id.yap and get_p_#id.yap), the router should prioritize the more specific match. Therefore, a GET /p/:id request would be handled by get_p_#id.yap over *_p_#id.yap, given the explicit mention of the GET method in the former.

Rationale

Flexibility: This enhancement would offer developers greater flexibility in defining their APIs, allowing for more concise and powerful routing configurations.
Convenience: By supporting multiple methods in a single route definition, we reduce redundancy and make route management more straightforward.

Conclusion

I believe these enhancements will make Yap more powerful and flexible, catering to a broader range of routing requirements.