This is an automated email from the ASF dual-hosted git repository.
guoqi pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new cf3fb4e20f7 docs: fix blog description (#1836)
cf3fb4e20f7 is described below
commit cf3fb4e20f79e04add4e861a966578ecb0cae10e
Author: Yilia Lin <[email protected]>
AuthorDate: Mon Dec 9 15:06:03 2024 +0800
docs: fix blog description (#1836)
---
blog/en/blog/2023/03/16/grpc-client-side.md | 16 ++++++++--------
blog/en/blog/2023/08/17/ops-friendly-apisix.md | 10 +++++-----
.../en/blog/2023/10/05/resize-images-on-the-fly.md | 22 ++++++++++++----------
blog/en/blog/2023/11/09/api-versioning.md | 8 ++++----
.../2024/02/13/apisix-owasp-coraza-core-ruleset.md | 6 ------
.../2024/02/20/secure-api-practices-apisix-1.md | 17 -----------------
.../2024/02/27/secure-api-practices-apisix-2.md | 21 +--------------------
7 files changed, 30 insertions(+), 70 deletions(-)
diff --git a/blog/en/blog/2023/03/16/grpc-client-side.md
b/blog/en/blog/2023/03/16/grpc-client-side.md
index ad3797dd6d2..725fd4d519d 100644
--- a/blog/en/blog/2023/03/16/grpc-client-side.md
+++ b/blog/en/blog/2023/03/16/grpc-client-side.md
@@ -18,11 +18,7 @@ tags: [Ecosystem]
image: https://static.apiseven.com/uploads/2023/06/08/DOxFlzQc_grpc.svg
---
->Most inter-systems communication components that use REST serialize their
payload in JSON. As of now, JSON lacks a widely-used schema validation
standard: [JSON Schema](https://json-schema.org/) is not widespread. Standard
schema validation allows delegating the validation to a third-party library and
being done with it. Without one, we must fall back to manual validation in the
code. Worse, we must keep the validation code in sync with the schema.
->
->XML has schema validation out-of-the-box: an XML document can declare a
grammar that it must conform to. SOAP, being based on XML, benefits from it too.
->
->Other serialization alternatives have a schema validation option: _e.g._,
[Avro](https://avro.apache.org/),
[Kryo](https://github.com/EsotericSoftware/kryo) and [Protocol
Buffers](https://protobuf.dev/). Interestingly enough, gRPC uses Protobuf to
offer RPC across distributed components:
+>In this post, we will briefly describe gRPC and how it benefits inter-service
communication.
<!--truncate-->
@@ -30,9 +26,13 @@ image:
https://static.apiseven.com/uploads/2023/06/08/DOxFlzQc_grpc.svg
<link rel="canonical" href="https://blog.frankel.ch/grpc-client-side/"; />
</head>
->gRPC is a modern open source high performance Remote Procedure Call (RPC)
framework that can run in any environment. It can efficiently connect services
in and across data centers with pluggable support for load balancing, tracing,
health checking and authentication. It is also applicable in last mile of
distributed computing to connect devices, mobile applications and browsers to
backend services.
->
->-- [Why gRPC?](https://grpc.io/)
+Most inter-systems communication components that use REST serialize their
payload in JSON. As of now, JSON lacks a widely-used schema validation
standard: [JSON Schema](https://json-schema.org/) is not widespread. Standard
schema validation allows delegating the validation to a third-party library and
being done with it. Without one, we must fall back to manual validation in the
code. Worse, we must keep the validation code in sync with the schema.
+
+XML has schema validation out-of-the-box: an XML document can declare a
grammar that it must conform to. SOAP, being based on XML, benefits from it too.
+
+Other serialization alternatives have a schema validation option: _e.g._,
[Avro](https://avro.apache.org/),
[Kryo](https://github.com/EsotericSoftware/kryo) and [Protocol
Buffers](https://protobuf.dev/). Interestingly enough, gRPC uses Protobuf to
offer RPC across distributed components:
+
+gRPC is a modern open source high performance Remote Procedure Call (RPC)
framework that can run in any environment. It can efficiently connect services
in and across data centers with pluggable support for load balancing, tracing,
health checking and authentication. It is also applicable in last mile of
distributed computing to connect devices, mobile applications and browsers to
backend services. -- [Why gRPC?](https://grpc.io/)
Moreover, Protocol is a _binary_ serialization mechanism, saving a lot of
bandwidth. Thus, gRPC is an excellent option for inter-systems communication.
But if all your components talk gRPC, how can simple clients call them? In this
post, we will build a gRPC service and show how to call it from curl.
diff --git a/blog/en/blog/2023/08/17/ops-friendly-apisix.md
b/blog/en/blog/2023/08/17/ops-friendly-apisix.md
index ad519599ff4..f1aea6c0e96 100644
--- a/blog/en/blog/2023/08/17/ops-friendly-apisix.md
+++ b/blog/en/blog/2023/08/17/ops-friendly-apisix.md
@@ -18,11 +18,7 @@ tags: [Ecosystem]
image: https://static.apiseven.com/2022/10/19/634f6677742a1.png
---
->Though I always worked on the Dev side of IT, I was also interested in the
Ops side. I even had a short experience being a WebSphere admin: I used it
several times, helping Ops deal with the Admin console while being a developer.
->
->Providing a single package that Ops can configure and deploy in different
environments is very important. As a JVM developer, I've been happy using
Spring Boot and its wealth of configuration options: command-line parameters,
JVM parameters, files, profiles, environment variables, etc.
->
->In this short post, I'd like to describe how you can do the same with Apache
APISIX in the context of containers.
+>In this short post, I'd like to describe how to leverage Apache APISIX in
containers, drawing on personal experiences with Spring Boot and WebSphere
administration.
<!--truncate-->
@@ -30,6 +26,10 @@ image:
https://static.apiseven.com/2022/10/19/634f6677742a1.png
<link rel="canonical" href="https://blog.frankel.ch/ops-friendly-apisix/";
/>
</head>
+Though I always worked on the Dev side of IT, I was also interested in the Ops
side. I even had a short experience being a WebSphere admin: I used it several
times, helping Ops deal with the Admin console while being a developer.
+
+Providing a single package that Ops can configure and deploy in different
environments is very important. As a JVM developer, I've been happy using
Spring Boot and its wealth of configuration options: command-line parameters,
JVM parameters, files, profiles, environment variables, etc.
+
## File-based configuration
The foundation of configuring Apache APISIX is file-based. The default values
are found in the `/usr/local/apisix/conf/apisix/config-default.yaml`
configuration file. For example, by default, Apache APISIX runs on port `9080`,
and the admin port is `9180`. That's because of the default configuration:
diff --git a/blog/en/blog/2023/10/05/resize-images-on-the-fly.md
b/blog/en/blog/2023/10/05/resize-images-on-the-fly.md
index 7b7d16d50dc..ce874cbb09d 100644
--- a/blog/en/blog/2023/10/05/resize-images-on-the-fly.md
+++ b/blog/en/blog/2023/10/05/resize-images-on-the-fly.md
@@ -19,8 +19,16 @@ tags: [Ecosystem]
image:
https://static.apiseven.com/uploads/2023/10/03/LuagzWfs_camera-514992.jpg
---
->As a web architect, one of the many issues is asset management. And the most
significant issue in assets is images. A naive approach would be to set an
image and let the browser resize the image via CSS:
->
+>This blog xplores effective strategies for image asset management in web
architecture, highlighting traditional and innovative solutions to optimize
delivery and avoid reliance on CSS resizing.
+
+<!--truncate-->
+
+<head>
+ <link rel="canonical"
href="https://blog.frankel.ch/resize-images-on-the-fly/"; />
+</head>
+
+As a web architect, one of the many issues is asset management. And the most
significant issue in assets is images. A naive approach would be to set an
image and let the browser resize the image via CSS:
+
>```css
>img {
> height: 100%;
@@ -28,16 +36,10 @@ image:
https://static.apiseven.com/uploads/2023/10/03/LuagzWfs_camera-514992.jpg
> object-fit: contain;
>}
>```
->
->However, it means that you download the original image. It entails two
problems: the size of the original image and the suboptimal browser-based
resizing.
->
->This post will cover two alternatives: traditional and brand-new solutions.
-<!--truncate-->
+However, it means that you download the original image. It entails two
problems: the size of the original image and the suboptimal browser-based
resizing.
-<head>
- <link rel="canonical"
href="https://blog.frankel.ch/resize-images-on-the-fly/"; />
-</head>
+This post will cover two alternatives: traditional and brand-new solutions.
## Ahead-of-time resizing
diff --git a/blog/en/blog/2023/11/09/api-versioning.md
b/blog/en/blog/2023/11/09/api-versioning.md
index 9c935d77892..91521a1fea6 100644
--- a/blog/en/blog/2023/11/09/api-versioning.md
+++ b/blog/en/blog/2023/11/09/api-versioning.md
@@ -20,10 +20,6 @@ image:
https://static.apiseven.com/uploads/2023/11/06/PjxXv0E9_signpost-3691159.
---
>In my previous post [Evolving your
>APIs](https://blog.frankel.ch/evolve-apis/), I mention the main API
>versioning approaches. During the talk of the same name, I sometimes get some
>questions on the subject. In this post, I'll detail each of them.
->
->I assume readers know the reasons behind versioning, semantic versioning, and
product lifecycle. If not, I encourage you to read a bit about these themes; in
particular, chapter 24 of the excellent [API Design
Patterns](https://blog.frankel.ch/api-design-patterns/) book focuses on them.
->
->I'll summarize the subject in a few words in any case.
<!--truncate-->
@@ -31,6 +27,10 @@ image:
https://static.apiseven.com/uploads/2023/11/06/PjxXv0E9_signpost-3691159.
<link rel="canonical" href="https://blog.frankel.ch/api-versioning/"; />
</head>
+I assume readers know the reasons behind versioning, semantic versioning, and
product lifecycle. If not, I encourage you to read a bit about these themes; in
particular, chapter 24 of the excellent [API Design
Patterns](https://blog.frankel.ch/api-design-patterns/) book focuses on them.
+
+I'll summarize the subject in a few words in any case.
+
## Generalities
Software naturally evolves, because of business need or changing regulations.
In some cases, the said software has no clients but humans, _e.g._, a monolith
with Server-Side Rendering. In all other cases, at least another software
component interacts with your software:
diff --git a/blog/en/blog/2024/02/13/apisix-owasp-coraza-core-ruleset.md
b/blog/en/blog/2024/02/13/apisix-owasp-coraza-core-ruleset.md
index 05a16c6b71a..8f51d77f715 100644
--- a/blog/en/blog/2024/02/13/apisix-owasp-coraza-core-ruleset.md
+++ b/blog/en/blog/2024/02/13/apisix-owasp-coraza-core-ruleset.md
@@ -21,12 +21,6 @@ image:
https://static.apiseven.com/uploads/2024/02/10/vVlFQu7C_img-HDlf4Xx9m1iqS
<link rel="canonical"
href="https://blog.frankel.ch/apisix-owasp-coraza-core-ruleset/"; />
</head>
->The Open Worldwide Application Security Project is an online community that
produces freely available articles, methodologies, documentation, tools, and
technologies in the fields of IoT, system software and web application
security. The OWASP provides free and open resources. It is led by a non-profit
called The OWASP Foundation. The OWASP Top 10 - 2021 is the published result of
recent research based on comprehensive data compiled from over 40 partner
organizations.
->
-> --[OWASP website](https://owasp.org/)
->
->The OWASP regularly publishes a Top 10 vulnerability report. The report
targets vulnerabilities in web applications.
->
>In this post, I'd like to describe how to fix some of them via the [Apache
>APISIX API Gateway](https://apisix.apache.org/).
<!--truncate-->
diff --git a/blog/en/blog/2024/02/20/secure-api-practices-apisix-1.md
b/blog/en/blog/2024/02/20/secure-api-practices-apisix-1.md
index a0dd9b3456b..90e879ebe34 100644
--- a/blog/en/blog/2024/02/20/secure-api-practices-apisix-1.md
+++ b/blog/en/blog/2024/02/20/secure-api-practices-apisix-1.md
@@ -25,23 +25,6 @@ image:
https://static.apiseven.com/uploads/2024/02/15/kgIjhRXf_img-BuLDzx81CexYQ
>A couple of months ago, I stumbled upon this list of Secure your API with
>these [16 practices to secure your
>API](https://www.linkedin.com/posts/brijpandeyji_secure-your-api-with-these-16-practices-activity-7094020647529369601-5kzQ/):
>
-> 1. Authentication ๐ต๏ธ๏ธ - Verifies the identity of users accessing APIs.
-> 2. Authorization ๐ฆ - Determines permissions of authenticated users.
-> 3. Data Redaction ๐๏ธ - Obscures sensitive data for protection.
-> 4. Encryption ๐ - Encodes data so only authorized parties can decode it.
-> 5. Error Handling โ - Manages responses when things go wrong, avoiding
revealing sensitive info.
-> 6. Input Validation & Data Sanitization ๐งน - Checks input data and removes
harmful parts.
-> 7. Intrusion Detection Systems ๐ - Monitor networks for suspicious
activities.
-> 8. IP Whitelisting ๐ - Permits API access only from trusted IP addresses.
-> 9. Logging and Monitoring ๐ฅ๏ธ - Keeps detailed logs and regularly monitors
APIs.
->10. Rate Limiting โฑ๏ธ - Limits user requests to prevent overload.
->11. Secure Dependencies ๐ฆ - Ensures third-party code is free from
vulnerabilities.
->12. Security Headers ๐ - Enhances site security against types of attacks like
XSS.
->13. Token Expiry โณ - Regularly expiring and renewing tokens prevents
unauthorized access.
->14. Use of Security Standards and Frameworks ๐ - Guides your API security
strategy.
->15. Web Application Firewall ๐ฅ - Protects your site from HTTP-specific
attacks.
->16. API Versioning ๐ - Maintains different versions of your API for seamless
updates.
->
>While it's debatable whether some points relate to security, _e.g.,_,
>versioning, the list is a good starting point anyway. In this two-post
>series, I'd like to describe how we can implement each point with Apache
>APISXI (or not).
<!--truncate-->
diff --git a/blog/en/blog/2024/02/27/secure-api-practices-apisix-2.md
b/blog/en/blog/2024/02/27/secure-api-practices-apisix-2.md
index c13a4664d52..d021330de12 100644
--- a/blog/en/blog/2024/02/27/secure-api-practices-apisix-2.md
+++ b/blog/en/blog/2024/02/27/secure-api-practices-apisix-2.md
@@ -23,26 +23,7 @@ image:
https://static.apiseven.com/uploads/2024/02/15/kgIjhRXf_img-BuLDzx81CexYQ
<link rel="canonical"
href="https://blog.frankel.ch/secure-api-practices-apisix/2/"; />
</head>
->[Last week](https://blog.frankel.ch/secure-api-practices-apisix/1/), we
listed 16 practices to help secure one's APIs and described how to implement
them with Apache APISIX.
->
-> 1. ~~Authentication ๐ต๏ธ๏ธ - Verifies the identity of users accessing APIs.~~
-> 2. ~~Authorization ๐ฆ - Determines permissions of authenticated users.~~
-> 3. Data Redaction ๐๏ธ - Obscures sensitive data for protection.
-> 4. Encryption ๐ - Encodes data so only authorized parties can decode it.
-> 5. Error Handling โ - Manages responses when things go wrong, avoiding
revealing sensitive info.
-> 6. ~~Input Validation & Data Sanitization ๐งน - Checks input data and removes
harmful parts.~~
-> 7. Intrusion Detection Systems ๐ - Monitor networks for suspicious
activities.
-> 8. ~~IP Whitelisting ๐ - Permits API access only from trusted IP addresses.~~
-> 9. ~~Logging and Monitoring ๐ฅ๏ธ - Keeps detailed logs and regularly monitors
APIs.~~
->10. ~~Rate Limiting โฑ๏ธ - Limits user requests to prevent overload.~~
->11. Secure Dependencies ๐ฆ - Ensures third-party code is free from
vulnerabilities.
->12. Security Headers ๐ - Enhances site security against types of attacks like
XSS.
->13. Token Expiry โณ - Regularly expiring and renewing tokens prevents
unauthorized access.
->14. Use of Security Standards and Frameworks ๐ - Guides your API security
strategy.
->15. Web Application Firewall ๐ฅ - Protects your site from HTTP-specific
attacks.
->16. API Versioning ๐ - Maintains different versions of your API for seamless
updates.
->
->This week, we will look at the remaining practices.
+>[Last week](https://blog.frankel.ch/secure-api-practices-apisix/1/), we
listed 16 practices to help secure one's APIs and described how to implement
them with Apache APISIX. This week, we will look at the remaining practices.
<!--truncate-->
