질문자 :Abdulaziz
웹 서비스 통신 프로토콜로서 SOAP와 REST의 차이점에 대한 기사를 읽었지만 SOAP에 비해 REST의 가장 큰 장점은 다음과 같습니다.
REST는 더 동적이고 UDDI(Universal Description, Discovery, and Integration)를 생성하고 업데이트할 필요가 없습니다.
REST는 XML 형식에만 국한되지 않습니다. RESTful 웹 서비스는 일반 텍스트/JSON/XML을 보낼 수 있습니다.
그러나 SOAP는 더 표준화되어 있습니다(예: 보안).
그래서, 나는 이러한 점에서 옳은가?
불행히도 REST에 대한 잘못된 정보와 오해가 많이 있습니다. 귀하의 질문과 @cmd의 답변은 이를 반영할 뿐만 아니라 Stack Overflow의 주제와 관련된 대부분의 질문과 답변을 반영합니다.
SOAP와 REST는 직접 비교할 수 없습니다. 첫 번째는 프로토콜이고(또는 최소한 그렇게 하려고 시도하는) 두 번째는 아키텍처 스타일이기 때문입니다. 사람들이 SOAP가 아닌 HTTP API를 REST 호출하는 경향이 있기 때문에 이것은 아마도 혼란의 원인 중 하나일 것입니다.
약간 밀어붙이고 비교를 설정하려고 하면 SOAP와 REST의 주요 차이점은 클라이언트와 서버 구현 간의 결합 정도입니다. SOAP 클라이언트는 서버에 밀접하게 결합된 맞춤형 데스크탑 애플리케이션처럼 작동합니다. 클라이언트와 서버 사이에는 엄격한 계약이 있으며 어느 한쪽이 변경하면 모든 것이 깨질 것으로 예상됩니다. 변경 후 지속적인 업데이트가 필요하지만 계약이 준수되고 있는지 확인하는 것이 더 쉽습니다.
REST 클라이언트는 브라우저와 비슷합니다. 프로토콜과 표준화된 방법을 사용하는 방법을 알고 있는 일반 클라이언트이며 애플리케이션이 그 안에 맞아야 합니다. 추가 방법을 만들어 프로토콜 표준을 위반하지 않고 표준 방법을 활용하고 미디어 유형에 대한 작업을 만듭니다. 올바르게 수행되면 결합이 줄어들고 변경 사항을 더 우아하게 처리할 수 있습니다. 클라이언트는 진입점과 미디어 유형을 제외하고 API에 대한 지식이 전혀 없는 상태에서 REST 서비스에 진입해야 합니다. SOAP에서 클라이언트는 사용할 모든 것에 대한 사전 지식이 필요합니다. 그렇지 않으면 상호 작용을 시작하지도 않습니다. 또한 REST 클라이언트는 서버 자체에서 제공하는 주문형 코드(code-on-demand)로 확장할 수 있습니다. 고전적인 예는 클라이언트 측에서 다른 서비스와의 상호 작용을 구동하는 데 사용되는 JavaScript 코드입니다.
REST가 무엇인지, SOAP와 어떻게 다른지 이해하는 데 다음이 중요한 포인트라고 생각합니다.
REST는 프로토콜에 독립적입니다. HTTP에 연결되어 있지 않습니다. 웹 사이트에서 ftp 링크를 따라갈 수 있는 것과 마찬가지로 REST 애플리케이션은 표준화된 URI 체계가 있는 모든 프로토콜을 사용할 수 있습니다.
REST는 CRUD를 HTTP 메서드로 매핑하는 것이 아닙니다. 이에 대한 자세한 설명은 이 답변을 읽으십시오.
REST는 사용 중인 부품만큼 표준화되어 있습니다. HTTP의 보안 및 인증은 표준화되어 있으므로 HTTP를 통해 REST를 수행할 때 사용하는 것입니다.
REST는 하이퍼미디어 와 HATEOAS 가 없는 REST가 아닙니다. 즉, 클라이언트는 진입점 URI만 알고 리소스는 클라이언트가 따라야 하는 링크를 반환해야 합니다. REST API에서 할 수 있는 모든 것에 대한 URI 패턴을 제공하는 멋진 문서 생성기는 요점을 완전히 놓치고 있습니다. 그들은 표준을 따라야 하는 것을 문서화할 뿐만 아니라 그렇게 할 때 클라이언트를 API 진화의 특정 순간에 연결하고 API의 모든 변경 사항을 문서화하고 적용해야 합니다. 또는 그것은 깨질 것입니다.
REST는 웹 자체의 아키텍처 스타일입니다. 스택 오버플로에 들어가면 사용자, 질문 및 답변이 무엇인지 알고 미디어 유형을 알고 웹 사이트에서 해당 링크를 제공합니다. REST API도 동일한 작업을 수행해야 합니다. 사람들이 REST가 수행되어야 한다고 생각하는 방식으로 웹을 설계했다면 질문과 답변에 대한 링크가 있는 홈 페이지 대신 질문을 보려면 URI stackoverflow.com/questions/<id> , id 를 Question.id 로 바꾸고 브라우저에 붙여넣으세요. 말도 안 되는 소리지만 많은 사람들이 REST를 그렇게 생각합니다.
이 마지막 점은 아무리 강조해도 지나치지 않습니다. 클라이언트가 문서의 템플릿에서 URI를 빌드하고 리소스 표현의 링크를 가져오지 않는 경우 REST가 아닙니다. REST의 저자인 Roy Fielding은 이 블로그 게시물에서 다음과 같이 분명히 했습니다. REST API는 하이퍼텍스트 기반이어야 합니다 .
위의 내용을 염두에 두고 REST가 XML로 제한되지 않을 수 있지만 다른 형식으로 올바르게 수행하려면 링크에 대한 일부 형식을 설계하고 표준화해야 합니다. 하이퍼링크는 XML에서 표준이지만 JSON에서는 그렇지 않습니다. HAL 과 같은 JSON에 대한 초안 표준이 있습니다.
마지막으로 REST는 모든 사람을 위한 것이 아니며 대부분의 사람들이 실수로 REST라고 부르는 HTTP API를 사용하여 문제를 매우 잘 해결하고 그 이상을 시도하지 않는다는 증거입니다. REST는 때때로 특히 처음에는 하기 어렵지만 서버 측에서 더 쉽게 진화하고 클라이언트가 변경 사항에 대해 탄력성을 갖게 되면서 시간이 지남에 따라 대가를 치르게 됩니다. 빠르고 쉽게 완료해야 하는 작업이 있으면 REST를 올바르게 설정하는 데 신경 쓰지 마세요. 아마도 당신이 찾고 있는 것이 아닐 것입니다. 몇 년 또는 수십 년 동안 온라인 상태를 유지해야 하는 것이 필요하다면 REST가 적합합니다.
REST 대 SOAP 는 올바른 질문 이 아닙니다.
REST SOAP 와 달리 프로토콜이 아닙니다.
REST 는 네트워크 기반 소프트웨어 아키텍처를 위한 아키텍처 스타일 이자 디자인입니다.
REST 개념을 리소스라고 합니다. 리소스 표현은 상태 비저장이어야 합니다. 일부 미디어 유형을 통해 표현됩니다. 미디어 유형의 몇 가지 예에는 XML , JSON 및 RDF 있습니다. 리소스는 구성 요소에 의해 조작됩니다. 구성 요소는 표준 균일 인터페이스를 통해 리소스를 요청하고 조작합니다. HTTP의 경우 이 인터페이스는 표준 HTTP 작업(예: GET , PUT , POST , DELETE 됩니다.
@Abdulaziz의 질문은 REST 와 HTTP 가 종종 함께 사용된다는 사실을 보여줍니다. 이것은 주로 HTTP의 단순성과 RESTful 원칙에 대한 매우 자연스러운 매핑 때문입니다.
클라이언트-서버 통신
클라이언트-서버 아키텍처에는 매우 뚜렷한 관심사 분리가 있습니다. RESTful 스타일로 구축된 모든 애플리케이션은 원칙적으로 클라이언트-서버여야 합니다.
무국적자
서버에 대한 각 클라이언트 요청에는 해당 상태가 완전히 표시되어야 합니다. 서버는 서버 컨텍스트나 서버 세션 상태를 사용하지 않고 클라이언트 요청을 완전히 이해할 수 있어야 합니다. 따라서 모든 상태는 클라이언트에서 유지되어야 합니다.
캐시 가능
캐시 제약 조건을 사용할 수 있으므로 응답 데이터를 캐시 가능 또는 캐시 불가능으로 표시할 수 있습니다. 캐시 가능으로 표시된 모든 데이터는 동일한 후속 요청에 대한 응답으로 재사용될 수 있습니다.
균일한 인터페이스
모든 구성 요소는 단일 인터페이스를 통해 상호 작용해야 합니다. 모든 구성 요소 상호 작용이 이 인터페이스를 통해 발생하기 때문에 다른 서비스와의 상호 작용은 매우 간단합니다. 인터페이스는 동일합니다! 이것은 또한 구현 변경이 개별적으로 이루어질 수 있음을 의미합니다. 이러한 변경은 균일한 인터페이스가 항상 변경되지 않기 때문에 기본적인 구성 요소 상호 작용에 영향을 미치지 않습니다. 한 가지 단점은 인터페이스에 갇혀 있다는 것입니다. 인터페이스를 변경하여 특정 서비스에 최적화를 제공할 수 있는 경우 REST가 이를 금지하므로 운이 좋지 않습니다. 그러나 긍정적인 측면에서 REST는 웹에 최적화되어 있으므로 HTTP를 통한 REST의 인기가 대단합니다!
위의 개념은 REST의 정의 특성을 나타내며 REST 아키텍처를 웹 서비스와 같은 다른 아키텍처와 차별화합니다. REST 서비스는 웹 서비스이지만 웹 서비스가 반드시 REST 서비스일 필요는 없다는 점에 유의하는 것이 유용합니다.
REST 및 위에 언급된 글머리 기호에 대한 자세한 내용은 REST 디자인 원칙에 대한 이 블로그 게시물 을 참조하세요.
편집: 댓글을 기반으로 콘텐츠 업데이트
SOAP( Simple Object Access Protocol ) 및 REST( Representation State Transfer )는 둘 다 나름대로 아름답습니다. 그래서 나는 그들을 비교하지 않습니다. 대신 REST를 선호할 때와 SOAP를 사용할 때의 그림을 묘사하려고 합니다.
페이로드 란 무엇입니까?
데이터가 인터넷을 통해 전송될 때 전송되는 각 단위에는 헤더 정보와 전송되는 실제 데이터가 모두 포함됩니다. 헤더는 패킷의 소스와 대상을 식별하는 반면 실제 데이터는 페이로드라고 합니다 . 일반적으로 페이로드는 애플리케이션을 대신하여 전달되는 데이터와 대상 시스템에서 수신한 데이터입니다.
예를 들어 이제 전보 를 보내야 하고 전보 비용이 일부 단어에 따라 달라질 것이라는 것을 우리 모두 알고 있습니다.
그럼 아래에 언급된 두 메시지 중 어느 쪽이 더 저렴하게 보낼 수 있는지 알려주세요.
<name>Arin</name>또는
"name": "Arin"두 번째 동일한 메시지를 나타내는 두 번째 답변이 비용면에서 더 저렴하지만 귀하의 답변이 두 번째 답변이 될 것이라는 것을 알고 있습니다.
그래서 JSON 형식으로 네트워크를 통해 데이터를 보내는 것이 페이로드와 관련하여 XML 형식으로 보내는 것보다 저렴 하다고 말하려고 합니다.
다음은 SOAP에 대한 REST의 첫 번째 이점입니다 . SOAP는 XML만 지원하지만 REST는 텍스트, JSON, XML 등과 같은 다른 형식을 지원합니다. 그리고 우리는 이미 알고 있습니다. Json을 사용한다면 확실히 페이로드와 관련하여 더 나은 위치에 있게 될 것입니다.
이제 SOAP는 유일한 XML을 지원 하지만 장점도 있습니다.
정말로! 어떻게?
SOAP는 메시지의 내용과 처리 방법을 정의하는 Envelope의 세 가지 방식으로 XML에 의존합니다.
데이터 유형에 대한 인코딩 규칙 세트, 그리고 마지막으로 수집된 프로시저 호출 및 응답의 레이아웃입니다.
이 봉투는 전송(HTTP/HTTPS)을 통해 전송되고 RPC(원격 프로시저 호출)가 실행되고 봉투는 XML 형식의 문서에 정보와 함께 반환됩니다.
중요한 점은 SOAP의 장점 중 하나가 "일반" 전송을 사용하지만 REST는 HTTP/HTTPS를 사용 한다는 것입니다. SOAP는 거의 모든 전송을 사용하여 요청을 보낼 수 있지만 REST는 그렇지 않습니다. 그래서 여기에서 우리는 SOAP를 사용하는 이점을 얻었습니다.
위의 "REST는 HTTP/HTTPS를 사용합니다" 단락에서 이미 언급했듯이 이 단어에 대해 좀 더 자세히 알아보십시오.
REST over HTTP에 대해 이야기할 때 HTTP에 적용된 모든 보안 조치는 상속되며 이를 전송 수준 보안 이라고 하며 유선 내부에 있는 동안에만 메시지를 보호하지만 다른 쪽에서 전달한 후에는 알 수 없습니다. 데이터가 처리될 실제 지점에 도달하기 전에 거쳐야 하는 단계 수. 물론 이러한 모든 단계는 HTTP와 다른 것을 사용할 수 있습니다. 그러니 휴식이 완전히 안전한 것은 아니겠죠?
그러나 SOAP는 REST와 마찬가지로 SSL을 추가로 지원하며 일부 엔터프라이즈 보안 기능을 추가 하는 WS-Security도 지원합니다. WS-Security는 메시지 생성 부터 소비까지 보호합니다. 따라서 전송 수준 보안의 경우 WS-Security를 사용하여 방지할 수 있는 허점이 발견되었습니다.
그 외에도 REST는 HTTP 프로토콜에 의해 제한 되므로 트랜잭션 지원은 ACID를 준수하지 않으며 분산된 초국가적 리소스에서 2단계 커밋을 제공할 수 없습니다.
그러나 SOAP는 단기 트랜잭션에 대한 ACID 기반 트랜잭션 관리 와 장기 트랜잭션에 대한 보상 기반 트랜잭션 관리 모두를 포괄적으로 지원합니다. 또한 분산 리소스 전반에 걸쳐 2단계 커밋을 지원합니다.
결론을 내리는 것은 아니지만 보안, 트랜잭션 등이 주요 관심사인 동안 SOAP 기반 웹 서비스를 선호합니다.
다음은 다음 조건이 충족될 때 RESTful 디자인이 적절할 수 있다고 말한 "Java EE 6 자습서"입니다. 보세요.
제 답변을 재미있게 읽으셨기를 바랍니다.
REST (RE 표현상 테이트 S T를 ransfer)
RE 표상 S 탓 T는 우리가 객체의 상태를 보내, 나머지는 우리가 객체를 전송하지 않습니다 즉이다 ransferred 인 객체의. REST는 아키텍처 스타일입니다. SOAP와 같은 많은 표준을 정의하지 않습니다. REST는 데이터에 대한 CRUD 작업을 처리하기 위해 인터넷을 통해 공용 API(예: Facebook API, Google Maps API)를 노출하기 위한 것입니다. REST는 일관된 단일 인터페이스를 통해 명명된 리소스에 액세스하는 데 중점을 둡니다.
SOAP (들 imple O bject CCESS rotocol P)
SOAP는 자체 프로토콜을 제공하고 애플리케이션 로직(데이터 아님)을 서비스로 노출하는 데 중점을 둡니다. SOAP는 작업을 노출합니다. SOAP는 명명된 작업에 액세스하는 데 중점을 두고 있으며 각 작업은 일부 비즈니스 논리를 구현합니다. SOAP는 일반적으로 웹 서비스 라고 하지만 이는 잘못된 명칭입니다. SOAP는 웹과 관련이 거의 없습니다. REST는 URI와 HTTP를 기반으로 진정한 웹 서비스를 제공합니다.
왜 REST인가?
application/xml 또는 application/json POST 및 /user/1234.json 또는 GET /user/1234.xml GET합니다.왜 SOAP인가?
IMHO 두 가지가 다른 SOAP와 REST를 비교할 수 없습니다.
SOAP 는 프로토콜이고 REST 는 소프트웨어 아키텍처 패턴입니다. SOAP 대 REST 에 대한 인터넷에는 많은 오해가 있습니다.
SOAP 는 웹 서비스 사용 응용 프로그램이 인터넷을 통해 서로 통신하는 데 사용하는 XML 기반 메시지 형식을 정의합니다. 이를 위해 애플리케이션은 메시지 계약, 데이터 유형 등에 대한 사전 지식이 필요합니다.
REST 는 URL에서 서버의 상태(리소스)를 나타냅니다. 상태 비저장이며 클라이언트는 하이퍼 미디어 이해를 넘어 서버와 상호 작용하는 사전 지식이 없어야 합니다.
우선 공식적으로 올바른 질문은
web services + WSDL + SOAP대REST입니다.웹 서비스 가 느슨한 의미로 사용되기는 하지만 HTTP 프로토콜을 사용하여 웹 페이지 대신 데이터 를 전송할 때 공식적 으로는 그 아이디어의 매우 구체적인 형태이기 때문입니다. 정의에 따르면 REST는 "웹 서비스"가 아닙니다.
그러나 실제로는 모두가 그것을 무시하므로 무시합시다.
이미 기술적인 답변이 있으므로 직관을 제공하려고 합니다.
원격 컴퓨터에서 다른 프로그래밍 언어로 구현된 함수를 호출하려고 한다고 가정해 보겠습니다(이를 종종 원격 프로시저 호출/RPC 라고 함). 함수를 작성한 사람이 제공한 특정 URL에서 함수를 찾을 수 있다고 가정합니다. (어떻게든) 메시지를 보내고 응답을 받아야 합니다. 따라서 고려해야 할 두 가지 주요 질문이 있습니다.
첫 번째 질문에 대한 공식 정의는 WSDL 입니다. 이것은 매개변수가 무엇인지, 매개변수의 유형, 이름, 기본값, 호출할 함수의 이름 등을 상세하고 엄격한 형식으로 설명하는 XML 파일입니다. 여기에서 WSDL의 예 는 파일이 사람임을 보여줍니다. -읽을 수 있습니다(그러나 쉽지는 않음).
두 번째 질문에는 다양한 답변이 있습니다. 그러나 실제로 사용되는 유일한 것은 SOAP 입니다. 주요 아이디어는 이전 XML(실제 메시지)을 또 다른 XML(인코딩 정보 및 기타 유용한 정보 포함)로 래핑하고 HTTP를 통해 전송하는 것입니다. HTTP의 POST 메서드는 항상 본문이 있기 때문에 메시지를 보내는 데 사용됩니다.
이 전체 접근 방식의 주요 아이디어는 URL을 함수 , 즉 action 에 매핑한다는 것입니다. 따라서 일부 서버에 고객 목록이 있고 이를 확인/업데이트/삭제하려면 3개의 URL이 있어야 합니다.
myapp/read-customer 및 메시지 본문에 읽을 고객의 ID를 전달합니다.myapp/update-customer 및 본문에서 고객의 ID와 새 데이터를 전달합니다.myapp/delete-customer 및 본문의 idREST 접근 방식은 상황을 다르게 봅니다. URL은 작업이 아니라 사물 (REST 용어 에서는 리소스 라고 함)을 나타내야 합니다. 우리가 이미 사용하고 있는 HTTP 프로토콜은 동사를 지원하므로 해당 동사를 사용 하여 사물에 수행할 작업을 지정합니다.
따라서 REST 접근 방식을 사용하면 고객 번호 12가 URL myapp/customers/12 에서 찾을 수 있습니다. 고객 데이터를 보려면 GET 요청이 있는 URL을 누르십시오. 동일한 URL을 삭제하려면 DELETE 동사를 사용합니다. 다시 업데이트하려면 POST 동사가 있는 동일한 URL과 요청 본문의 새 콘텐츠가 필요합니다.
서비스가 진정한 RESTful로 간주되기 위해 충족해야 하는 요구 사항에 대한 자세한 내용은 Richardson 성숙도 모델을 참조하세요. 이 기사는 예제를 제공하고 더 중요하게는 (소위) SOAP 서비스가 레벨 0 REST 서비스인 이유를 설명합니다(레벨 0은 이 모델에 대한 낮은 준수를 의미하지만 공격적이지 않으며 여전히 유용합니다. 많은 경우에).
많은 답변에서 이미 다룬 많은 답변 중에서 SOAP를 통해 계약, 지원되는 작업을 정의하는 WSDL, 복잡한 유형 등을 정의할 수 있다는 점을 강조하고 싶습니다. SOAP는 작업을 지향하지만 REST는 리소스를 지향합니다. 개인적으로 내부 엔터프라이즈 응용 프로그램 간의 복잡한 인터페이스에는 SOAP를 선택하고 외부 세계와의 더 간단하고 상태 비저장적인 공용 인터페이스에는 REST를 선택합니다.
추가:
++ REST에 접근할 때 자주 저지르는 실수는 REST를 "URL이 있는 웹 서비스"로 생각하는 것입니다. REST를 SOAP와 같은 또 다른 원격 프로시저 호출(RPC) 메커니즘으로 생각하지만 일반 HTTP URL을 통해 호출되고 SOAP의 무거운 XML 네임스페이스.
++ 반대로 REST는 RPC와 거의 관련이 없습니다. RPC가 서비스 지향적이며 작업과 동사에 중점을 둔 반면 REST는 애플리케이션을 구성하는 사물과 명사를 강조하는 리소스 지향적입니다.
이 답변 중 많은 부분이 REST에 완전히 기본적인 하이퍼미디어 제어(HATEOAS)를 언급하는 것을 완전히 잊었습니다. 몇몇 다른 사람들이 그것에 대해 만졌지만 실제로 그렇게 잘 설명하지는 않았습니다.
이 기사에서는 특정 SOAP 기능에 대해 자세히 설명하지 않고 개념 간의 차이점을 설명해야 합니다.
REST 란 무엇입니까?
REST는 표현 상태 전송(representational state transfer)을 의미하며, 실제로는 모든 것(데이터 또는 기능)을 자원으로 취급하는 Web API를 생성하기 위한 아키텍처 스타일입니다. 그것은 기대한다; URI를 통해 리소스를 노출하고 여러 형식으로 응답하고 상태가 없는 방식으로 리소스 상태를 표현적으로 전송합니다. 여기서 나는 두 가지에 대해 이야기하고 있습니다.
REST는 개념이기 때문에 SOAP 웹 서비스를 사용할 수 있으며 HTTP와 같은 모든 프로토콜을 사용할 수 있습니다. SOAP.SOAP는 서비스 인터페이스를 사용하여 비즈니스 로직을 노출합니다. REST는 URI를 사용하여 비즈니스 로직을 노출합니다.
REST는 HATEOAS가 없는 REST가 아닙니다. 즉, 클라이언트는 진입점 URI만 알고 리소스는 클라이언트가 따라야 하는 링크를 반환해야 합니다. REST API에서 할 수 있는 모든 것에 대한 URI 패턴을 제공하는 멋진 문서 생성기는 요점을 완전히 놓치고 있습니다. 그들은 표준을 따라야 하는 것을 문서화할 뿐만 아니라 그렇게 할 때 클라이언트를 API 진화의 특정 순간에 연결하고 API의 모든 변경 사항을 문서화하고 적용해야 합니다. 또는 그것은 깨질 것입니다.
HATEOAS는 Hypermedia As The Engine Of Application State의 약자로 대부분의 다른 네트워크 애플리케이션 아키텍처와 구별되는 REST 애플리케이션 아키텍처의 제약 조건입니다. 원칙은 클라이언트가 전적으로 애플리케이션 서버에서 동적으로 제공되는 하이퍼미디어를 통해 네트워크 애플리케이션과 상호 작용한다는 것입니다. REST 클라이언트는 하이퍼미디어에 대한 일반적인 이해를 넘어 특정 애플리케이션이나 서버와 상호 작용하는 방법에 대한 사전 지식이 필요하지 않습니다. 대조적으로, 일부 서비스 지향 아키텍처(SOA)에서 클라이언트와 서버는 문서 또는 IDL(인터페이스 설명 언어)을 통해 공유되는 고정 인터페이스를 통해 상호 작용합니다.
SOAP와 REST는 HTTP 프로토콜을 통해 유사점을 공유하지만 SOAP는 REST보다 더 엄격한 메시징 패턴 집합입니다. SOAP의 규칙은 그것들 없이는 어느 정도의 표준화를 달성할 수 없기 때문에 관련이 있습니다. REST는 아키텍처 스타일로 처리할 필요가 없으며 본질적으로 더 다양합니다. 정보 교환의 정신에서 SOAP와 REST는 모두가 준수하기로 결정한 잘 확립된 법률에 의존합니다. SOAP 대 REST의 선택은 사용 중인 환경과 사양에 따라 사용 중인 프로그래밍 언어에 따라 다릅니다.
출처 : http:www.stackoverflow.com/questions/19884295/soap-vs-rest-differences
| NaN 값을 어떻게 확인할 수 있습니까? (0) | 2023.04.24 |
|---|---|
| PostgreSQL 데이터베이스의 모든 테이블을 삭제하려면 어떻게 해야 합니까? (0) | 2023.04.24 |
| 문자열에서 공백을 어떻게 트리밍합니까? (0) | 2023.04.24 |
| 병합을 완료하지 않았습니다(MERGE_HEAD 존재). (1) | 2023.04.24 |
| Vim에서 줄 끝으로 어떻게 이동합니까? (0) | 2023.04.24 |